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 HEL
O
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 serve
r
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?

[ Post a follow-up to this message ]

Which server generated the NDR?
Likely a relay restriction, but it would be helpful to know which MTA
created the NDR.

Al


"skyline" <skyline@discussions.microsoft.com> wrote in message
news:325196A5-27FC-4883-8394-87C217F21AD0@microsoft.com...
> 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?
>

[ Post a follow-up to this message ]

The SMTP server generated the NDR.  Both servers are allowed to relay throug
h
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/ii...e_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@discussions.microsoft.com> wrote in message
> news:325196A5-27FC-4883-8394-87C217F21AD0@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]

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@discussions.microsoft.com> wrote in message
news:6A8971D9-49BB-4DA2-B4C2-E2D3CB5986BF@microsoft.com...[vbcol=seagreen]
> 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/ii...e_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:
> 

[ Post a follow-up to this message ]

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 mai
l
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 i
s
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 hav
e
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@discussions.microsoft.com> wrote in message
> news:6A8971D9-49BB-4DA2-B4C2-E2D3CB5986BF@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]

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@discussions.microsoft.com> wrote in message
news:58E605D0-087B-41F8-8DF1-988868564887@microsoft.com...[vbcol=seagreen]
> 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:
> 

[ Post a follow-up to this message ]

By the way the error from the system log is the log of the SMTP server.

"skyline" wrote:
[vbcol=seagreen]
> 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 te
ll
> it is a rather simple app designed just to send emails.  The destination m
ail
> servers are of all types, however the domains reporting problems are not
> Yahoo! users (they receive fine) but more specific smaller hosting compani
es
> 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 t
he
> remote domain 'lightbound.com' for the following reason: The connection wa
s
> 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 s
ee
> 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 whe
n
> sending.
>
> I find it super odd that the messages make it to the SMTP server and out t
o
> the destination but are dropped at that point.  It gets to the DATA comman
d
> and then never issues a quit so I am assuming that it dies during this tim
e.
>
> All of the failure notifications simply give the 4.4.7 action failed statu
s
> on return which is the code for a delay.  The email addresses in the failu
re
> 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 h
ave
> 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 sti
ll
> a necessity to figure out where the problem is here.
>
> Thanks for your help!
>
> "Al Mulnick" wrote:
> 

[ Post a follow-up to this message ]

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 en
d
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@discussions.microsoft.com> wrote in message
> news:58E605D0-087B-41F8-8DF1-988868564887@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]

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@discussions.microsoft.com> wrote in message
news:3FA4CA1D-92A7-484A-871F-23EA868595A7@microsoft.com...[vbcol=seagreen]
> 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:
> 

[ Post a follow-up to this message ]

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 o
f
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 mayb
e
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 expec
t
> 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-awar
e
> 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.8
4'
> 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@discussions.microsoft.com> wrote in message
> news:3FA4CA1D-92A7-484A-871F-23EA868595A7@microsoft.com... 
>
>
>

[ Post a follow-up to this message ]