SMTP servers should insert a Return-Path header, as per RFC 821 SMTP, but IMail does not.
This was discussed briefly about two years ago on this list, and the upshot was thus:
- IMail's SMTPD does indeed preserve the envelope sender (RFC <reverse-path>) after the messages leave the SMTP world, in the From delimiter in the mbox file. It is not necessary to reflect the info in a Return-Path: _header_, so IMail is thus RFC-compliant.
- The <reverse-path> so provided is viewable in any mail client that can read the mbox files natively. The <reverse-path> is, however, no longer viewable when the messages are downloaded using POP3D.
So the answer is that Imail is not, strictly speaking, RFC-wrong, but does not go out of its way to be right.
No, it's RFC-wrong.
RFC2821 (http://www.ietf.org/rfc/rfc2821.txt), section 4.4, Trace Information:
"When the delivery SMTP server makes the 'final delivery' of a message, it inserts a return-path line at the beginning of the mail data. This
use of return-path is required; mail systems MUST support it. The
return-path line preserves the information in the <reverse- path> from
the MAIL command."
How much clearer could that be? Sticking it in the mbox From_ line doesn't help any program that doesn't have access to the raw mbox file (such as a client accessing the mail via POP3).
So it appears that IMail has been aware of the issue for two years,
but its developers are too lazy to be bothered with SMTP standards. Sounds like a world-class organization.
--
James Thornton _____________________________________________ Internet Consultant, http://jamesthornton.com
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
