Re: Mail from: shows internal server name in mail header and fails
- From: "Al Mulnick" <amulnick_No_SPAM@xxxxxxxxxxx>
- Date: Wed, 14 Sep 2005 11:55:13 -0400
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
> 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?
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>
.
- Follow-Ups:
- References:
- Mail from: shows internal server name in mail header and fails
- From: skyline
- Re: Mail from: shows internal server name in mail header and fails
- From: Al Mulnick
- Re: Mail from: shows internal server name in mail header and fails
- From: skyline
- Re: Mail from: shows internal server name in mail header and fails
- From: Al Mulnick
- Re: Mail from: shows internal server name in mail header and fails
- From: skyline
- Mail from: shows internal server name in mail header and fails
- Prev by Date: Re: Win 2003 SMTP Sends one account, not others . . .
- Next by Date: Re: Mail from: shows internal server name in mail header and fails
- Previous by thread: Re: Mail from: shows internal server name in mail header and fails
- Next by thread: Re: Mail from: shows internal server name in mail header and fails
- Index(es):
Relevant Pages
|
Loading
