Our corporate email goes out to 1000+ Exchange mailboxes. The mass email
goes out using Outlook 2003. Somehow, looking at the internet header for the
corporate email, the return path is missing. Some email recipients are not
getting the corporate email due to the fact that one particular smtp gateway
blockes the email without the return path information. What causes to drop
the return path information in the header?
I don't think that the sending server controls the inclusion of the return
path header line. The SMTP transaction is very simple.
If there is a return path line added, it will be formed from the email
address in the "MAIL FROM" SMTP command, and stamped by the gateway mail
server. I don't see why a gateway mail server would block email lacking a
return path since it is the which stamps the return path email address.
As a test, I just sent myself an email, using Telnet to an MS virtual SMTP
server (part of the IIS services in Windows XP Pro). Here is a transcript of
the transaction, copied from the command prompt window:
| 220 kozue.aosake.net Microsoft ESMTP MAIL Service, Version: 6.0.2600.5512
| ready at Thu, 22 Jan 2009 18:12:30 -0800
| HELO hotmail.com
| 250 kozue.aosake.net Hello [192.168.102.34]
| MAIL FROM: <%UserID%@hotmail.com>
| 250 2.1.0 %UserID%@hotmail.com....Sender OK
| RCPT TO: <%UserID%@aosake.net>
| 250 2.1.5 %UserID%@aosake.net
| DATA:
| 500 5.3.3 Unrecognized command
| DATA
| 354 Start mail input; end with <CRLF>.<CRLF>
| Date: Jan. 27, 2009 18:13 PST (-07:00)
| Subject: [TEST] Just checking ...
| From: Proper Name <%UserID%@hotmail.com>
| To: Me <%UserID%@aosake.net>
|
| This is just an attempt to see how a gay mail server works.
| .
| 250 2.6.0 <
[email protected]> Queued mail for delivery
| quit
| 221 2.0.0 kozue.aosake.net Service closing transmission channel
As you can see, there is no return path header line included. Just the email
address in the MAIL FROM command line. Everything from "DATA" (the line
after the error!) is part of the email. The single space separates header
lines from the body of the email; but they are not creations of any email
server handling the email.
Here are the relevant headers from the received message:
| Return-path: <%UserID%@hotmail.com>
| Received: from kozue.aosake.net (192.168.102.34) by aosake.net (Mercury/32 v4.61) with ESMTP ID MG00014A;
| 22 Jan 2009 18:15:32 -0800
| Received: from hotmail.com ([192.168.102.34]) by kozue.aosake.net with Microsoft SMTPSVC(6.0.2600.5512);
| Thu, 22 Jan 2009 18:13:16 -0800
| Date: Jan. 27, 2009 18:13 PST (-07:00)
| Subject: [TEST] Just checking ...
| From: Proper Name <%UserID%@hotmail.com>
| To: Me <%UserID%@aosake.net>
| Message-ID: <
[email protected]>
| X-OriginalArrivalTime: 23 Jan 2009 02:15:01.0455 (UTC) FILETIME=[6595ADF0:01C97D00]
Since 'kozue.aosake.net' should not add anything, other than a header stamp
about the source of the email (the message submission client data), the only
header line actually included by 'kozue.aosake.net' is the "Recevied:" line
announcing the source (which wasn't really 'hotmail.com', but the computer
on which I ran the Telnet session). Thus the only header line stamped by
'kozue.aosake.net' (the local IIS virtual SMTP server) is this one:
| Received: from hotmail.com ([192.168.102.34]) by kozue.aosake.net with Microsoft SMTPSVC(6.0.2600.5512);
| Thu, 22 Jan 2009 18:13:16 -0800
The following header lines were stamped by 'aosake.net', which is the
gateway mail server for the domain (which server is Mercury/32):
| Return-path: <%UserID%@hotmail.com>
| Received: from kozue.aosake.net (192.168.102.34) by aosake.net (Mercury/32 v4.61) with ESMTP ID MG00014A;
| 22 Jan 2009 18:15:32 -0800
| Message-ID: <
[email protected]>
| X-OriginalArrivalTime: 23 Jan 2009 02:15:01.0455 (UTC) FILETIME=[6595ADF0:01C97D00]
These header lines are, in fact, the parts of the "DATA" command preceding
the single space:
| Date: Jan. 27, 2009 18:13 PST (-07:00)
| Subject: [TEST] Just checking ...
| From: Proper Name <%UserID%@hotmail.com>
| To: Me <%UserID%@aosake.net>
They were typed in after the SMTP "DATA" command. Something else than a
missing return path header line is afoot.
There is no information on the email client handling the email because I
composed the email directly, using Telnet, and did not send this email with
any email client.
