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

Tech-Archive recommends: Fix windows errors by optimizing your registry

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

"skyline" wrote:

> 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

  • Re: SOS! IIS Stopped working completely!
    ... Kristofer Gafvert - IIS MVP ... > Vilmar Brazão de Oliveira ... >> application), ASP Application, SQL Server ... >> when I try to load test.asp, I get the DCOM error in system log. ...
    (microsoft.public.inetserver.asp.general)
  • Re: SOS! IIS Stopped working completely!
    ... Kristofer Gafvert - IIS MVP ... > Vilmar Brazão de Oliveira ... >> application), ASP Application, SQL Server ... >> when I try to load test.asp, I get the DCOM error in system log. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: SOS! IIS Stopped working completely!
    ... Kristofer Gafvert - IIS MVP ... > Vilmar Brazão de Oliveira ... >> application), ASP Application, SQL Server ... >> when I try to load test.asp, I get the DCOM error in system log. ...
    (microsoft.public.inetserver.iis)
  • Re: Receiving CI Service Event 4149 & App Popup Event 333 on Win2k3 SP
    ... NetLogon Event ID 5719 in the System Log at approx the same time, ... remotely manage and also sometimes RDP to the server (other ... link between SQL and the issue occuring. ...
    (microsoft.public.windows.server.general)
  • Re: MAPILogonEx Error
    ... There isn't anything in the System Log, but in the App Log, the problem ... The MAPI call 'OpenMsgStore' failed with the following error: ... The logon to the Microsoft Exchange Server computer failed. ...
    (microsoft.public.exchange.admin)