Re: Mail from: shows internal server name in mail header and fails

You might want to trace the network between MTA1 and your egress point in
the meantime. Look for things like EHLO conversations and missing CRLF
combinations and look for the conversation ending verbs and data etc.

Might prove useful to see the conversation as it occurs regardless of what
the hosting company says. :)



"skyline" <skyline@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:91277848-EE52-4F97-9E0C-132657F5A645@xxxxxxxxxxxxxxxx
> I've noticed a new link in the chain. Inspecting most of the failed
> domains
> I have found a common link: those denying our mail seem to be running
> SquirrelMail and not Exchange/GroupWise/etc.
>
> client-application --->MTA1 (your server) --->MTA2 (Host:
> '206.246.140.84';
> refuses to take the mail 4.2.1).
>
> That would be the correct route. I have been through our logs with a fine
> tooth comb and see no real "reason" why we are getting denied. Since most
> of
> our clients are with a hosting company I am having to seek help from them
> to
> find out why they would deny us and as I am sure you know this is not easy
> since we are not customers. One is cooperating but rather slowly....so
> maybe
> I will get an answer through them.
>
> I appreciate your help and will post any additional findings or resolution
> if I can get one :)
>
> "Al Mulnick" wrote:
>
>> I should have read more closely. :)
>> You *could* filter by the ipaddr of the MUA, but you'd have to do that at
>> the first hop (in otherwords, the first server to receive the mail) else
>> have a program that looks for that specific information. I wouldn't
>> expect
>> it to be useful though as that information would not be considered stable
>> in
>> my opinion.
>>
>> If the message is received by your local server (same as the other
>> application) but is then denied at the next hop, then you need to look at
>> the recipient host or the communication between it if there is a
>> SMTP-aware
>> firewall between for the issue.
>>
>> client-application --->MTA1 (your server) --->MTA2 (Host:
>> '206.246.140.84';
>> refuses to take the mail 4.2.1).
>> Is that the correct way to express the problem? If so, then
>> '206.246.140.84'
>> is the host to check first and work your way back. Check the logs to see
>> why it was rejected and what it objects to.
>>
>> Al
>>
>>
>>
>>
>>
>> "skyline" <skyline@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:3FA4CA1D-92A7-484A-871F-23EA868595A7@xxxxxxxxxxxxxxxx
>> > Possible on the receiving end to filter by our internal application IP
>> > address? As far as our SMTP server we are allowing the internal
>> > communication but I did not know it was possible to deny on the
>> > receiving
>> > end
>> > based on our internal IP of the app server. Can you confirm that?
>> >
>> > "Al Mulnick" wrote:
>> >
>> >> It's absolutely possible to filter by IP address. It's on the
>> >> properties
>> >> of
>> >> the SMTP server under the access | relay tab (something like that :)
>> >>
>> >>
>> >> "skyline" <skyline@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> news:58E605D0-087B-41F8-8DF1-988868564887@xxxxxxxxxxxxxxxx
>> >> > The current workaround/resolution is to move this custom made
>> >> > application
>> >> > over to the original application server and it works like a charm.
>> >> > No
>> >> > changes to the application were made
>> >> >
>> >> > Both systems are Windows 2000 with matching network properties and
>> >> > as
>> >> > far
>> >> > as
>> >> > I can tell they are configured the same.
>> >> >
>> >> > The custom application is using .NET's email function. From what I
>> >> > can
>> >> > tell
>> >> > it is a rather simple app designed just to send emails. The
>> >> > destination
>> >> > mail
>> >> > servers are of all types, however the domains reporting problems are
>> >> > not
>> >> > Yahoo! users (they receive fine) but more specific smaller hosting
>> >> > companies
>> >> > such as lightbound.com are getting denied. Here is one of the
>> >> > errors
>> >> > from
>> >> > the system log:
>> >> >
>> >> > Message delivery to the host '206.246.140.84' failed while
>> >> > delivering
>> >> > to
>> >> > the
>> >> > remote domain 'lightbound.com' for the following reason: The
>> >> > connection
>> >> > was
>> >> > dropped by the remote host.
>> >> >
>> >> > Is it possible to filter by an internal IP in an email header (or a
>> >> > server
>> >> > name)? In the end of the initial hand off in the header you can
>> >> > plainly
>> >> > see
>> >> > our mail servers DNS name as the sender. The only difference is the
>> >> > HELO
>> >> > command to our internal server which I can't imagine is a problem.
>> >> > The
>> >> > IP
>> >> > is
>> >> > granted relay access just as the other one, and no errors are
>> >> > returned
>> >> > when
>> >> > sending.
>> >> >
>> >> > I find it super odd that the messages make it to the SMTP server and
>> >> > out
>> >> > to
>> >> > the destination but are dropped at that point. It gets to the DATA
>> >> > command
>> >> > and then never issues a quit so I am assuming that it dies during
>> >> > this
>> >> > time.
>> >> >
>> >> > All of the failure notifications simply give the 4.4.7 action failed
>> >> > status
>> >> > on return which is the code for a delay. The email addresses in the
>> >> > failure
>> >> > notification have the text RFC822 in front of each address. I
>> >> > thought
>> >> > we
>> >> > must be violating a procedure in that RFC but there are so many
>> >> > listed
>> >> > I
>> >> > have
>> >> > no way of telling which one(s) we may be violating.
>> >> >
>> >> > The people that receive the messages do not report them being
>> >> > different
>> >> > or
>> >> > bad and of course there is the handfull that simply don't receive
>> >> > them.
>> >> >
>> >> > We have worked around by putting back on the original server but it
>> >> > is
>> >> > still
>> >> > a necessity to figure out where the problem is here.
>> >> >
>> >> > Thanks for your help!
>> >> >
>> >> > "Al Mulnick" wrote:
>> >> >
>> >> >> Just for fun, is the destination mail server the same? Because the
>> >> >> DSN
>> >> >> indicates that it couldn't contact the destination and therefore
>> >> >> gave
>> >> >> the
>> >> >> message back. Is there a syntax error, or other?
>> >> >>
>> >> >> What are they using to generate the email in .NET? Are they
>> >> >> hand-crafting
>> >> >> the conversation (reinventing the wheel) or using some of the built
>> >> >> in
>> >> >> functions?
>> >> >>
>> >> >> Al
>> >> >>
>> >> >>
>> >> >> "skyline" <skyline@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> >> news:6A8971D9-49BB-4DA2-B4C2-E2D3CB5986BF@xxxxxxxxxxxxxxxx
>> >> >> > The SMTP server generated the NDR. Both servers are allowed to
>> >> >> > relay
>> >> >> > through
>> >> >> > the SMTP server and many clients get the emails from the new
>> >> >> > application
>> >> >> > server but some do not.
>> >> >> >
>> >> >> > We are investigating the following link as this may relate to the
>> >> >> > problem:
>> >> >> >
>> >> >> > http://www.dylanbeattie.net/docs/iis6_bare_linefeed.html
>> >> >> >
>> >> >> > Although we did not upgrade the version of IIS the new
>> >> >> > application
>> >> >> > server
>> >> >> > is
>> >> >> > running a .NET app different from the Adobe application on the
>> >> >> > first
>> >> >> > app
>> >> >> > server to generate the emails and I have the sneaking suspesion
>> >> >> > they
>> >> >> > programmed it incorrectly.
>> >> >> >
>> >> >> > Thanks for the reply and if you have any other thoughts please
>> >> >> > let
>> >> >> > me
>> >> >> > know.
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > "Al Mulnick" wrote:
>> >> >> >
>> >> >> >> Which server generated the NDR?
>> >> >> >> Likely a relay restriction, but it would be helpful to know
>> >> >> >> which
>> >> >> >> MTA
>> >> >> >> created the NDR.
>> >> >> >>
>> >> >> >> Al
>> >> >> >>
>> >> >> >>
>> >> >> >> "skyline" <skyline@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> >> >> >> news:325196A5-27FC-4883-8394-87C217F21AD0@xxxxxxxxxxxxxxxx
>> >> >> >> > Here is a background on our setup: we have one server that is
>> >> >> >> > setup
>> >> >> >> > as
>> >> >> >> > an
>> >> >> >> > SMTP relay that has an MX record configured and a FQDN. We
>> >> >> >> > have
>> >> >> >> > another
>> >> >> >> > application server creating messages via Adobe Central Pro and
>> >> >> >> > relaying
>> >> >> >> > them
>> >> >> >> > through this SMTP server. During the HELO to the internal
>> >> >> >> > SMTP
>> >> >> >> > server,
>> >> >> >> > the
>> >> >> >> > internal application server is "lying" to our internal SMTP
>> >> >> >> > server
>> >> >> >> > by
>> >> >> >> > saying
>> >> >> >> > HELO SMTPSERVERINTERNALIP during the communications as opposed
>> >> >> >> > to
>> >> >> >> > saying
>> >> >> >> > HELO
>> >> >> >> > MYINTERNALSERVERIP. This relaying has worked without a
>> >> >> >> > problem,
>> >> >> >> > and
>> >> >> >> > looking
>> >> >> >> > at successful mail headers we can see the following line:
>> >> >> >> >
>> >> >> >> > Received: From SMTPINTERNALIP {ADOBESERVERINTERNALIP} by
>> >> >> >> > mail.externaldns.com etc.
>> >> >> >> >
>> >> >> >> > Now we have added another application server to do some of
>> >> >> >> > this
>> >> >> >> > message
>> >> >> >> > creating. Initially it was configured to send this HELO
>> >> >> >> > command
>> >> >> >> > when
>> >> >> >> > connecting to the SMTP server:
>> >> >> >> >
>> >> >> >> > HELO NEWINTERNALSERVERNAME
>> >> >> >> >
>> >> >> >> > And looking at the mail header for this new server:
>> >> >> >> >
>> >> >> >> > from NEWINTERNALSERVERNAME ([NEWINTERNALSERVERNAMEIPADDRESS])
>> >> >> >> > by
>> >> >> >> > mail.externaldns.com etc
>> >> >> >> >
>> >> >> >> > So now since it is sending the servername in the HELO command
>> >> >> >> > many
>> >> >> >> > of
>> >> >> >> > our
>> >> >> >> > clients are not receiving emails from us from the new server.
>> >> >> >> > The
>> >> >> >> > old
>> >> >> >> > server
>> >> >> >> > configuration works fine still. Now our developers are
>> >> >> >> > changing
>> >> >> >> > the
>> >> >> >> > new
>> >> >> >> > application to match the existing one but I still wonder why
>> >> >> >> > on
>> >> >> >> > Earth
>> >> >> >> > messages using the INTERNALSERVERDNSNAME would stop working.
>> >> >> >> > For
>> >> >> >> > these
>> >> >> >> > addresses using the INTERNALSERVERDNSNAME we are receiving
>> >> >> >> > several
>> >> >> >> > delay
>> >> >> >> > notifications before sending the failure notification with a
>> >> >> >> > status
>> >> >> >> > of
>> >> >> >> > 4.4.7
>> >> >> >> > action failed. Here is the failure notification message:
>> >> >> >> >
>> >> >> >> > This is an automatically generated Delivery Status
>> >> >> >> > Notification.
>> >> >> >> >
>> >> >> >> > Unable to deliver message to the following recipients, due to
>> >> >> >> > being
>> >> >> >> > unable
>> >> >> >> > to connect successfully to the destination mail server.
>> >> >> >> >
>> >> >> >> > Can anyone provide any insight as to why this would occur?
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>


.

Relevant Pages

  • Communications Breakdown with CSocket
    ... A problem has arisen where communication between the two OCX's will be ... down is when the method SendPlayList or one of a couple other Server ... we have the server OCX instantiated and named ... On the receiving side within the client OCX, ...
    (microsoft.public.vc.mfc)
  • Communications Breakdown with CSocket
    ... A problem has arisen where communication between the two OCX's will be ... down is when the method SendPlayList or one of a couple other Server ... we have the server OCX instantiated and named ... On the receiving side within the client OCX, ...
    (comp.lang.cpp)
  • RE: SMTP Outgoing - Connection Dropped
    ... Then checked the result of the SMTP diag, ... Checking TCP/UDP SOA serial number using DNS server. ... conversation with the receiving Mail Server computer. ...
    (microsoft.public.windows.server.sbs)
  • Re: Is it possible to trace source of messages bearing Netsky.R or .Q?
    ... using that ip is not a real mail server but has been "trojaned" ... and if it's the ip address of the *receiving* server (ie your ... this is that if a hacker is directing spam ... the reception of viral e-mail ...
    (alt.comp.anti-virus)
  • RE: email from SBS being flagged as SPAM
    ... After you send an email to the receiving domain from company_two.com, ... the receiving server looks for the PTR record for company_two.com. ... This newsgroup only focuses on SBS technical issues. ...
    (microsoft.public.windows.server.sbs)