IMail: No Return-Path Header or Envelope Sender as Per RFC 821/2821

Home	Blog	Bio	Projects	Contact	Latest Blog (new site): How to Get to Genius

JamesThornton.com $-\>$ Writing $-\>$ IMail: No Return-Path Header or Envelope Sender as Per RFC 821/2821

IMail: No Return-Path Header or Envelope Sender as Per RFC 821/2821

Summary: Explains IMail's failure to record the return-path header in e-mail.

SMTP servers that follow RFC specification must insert a return-path header containing the envelope sender address when the e-mail arrives at its final destination and "leaves the SMTP world". Ipswitch claims IMail 8.0 is RFC 2821 compliant (PDF), but its cliam is false as IMail 8.0 does not follow the specification that all SMTP servers must insert a return-path header.

Inventing a return path by using the value in the from header is a bad idea.
Some mailers, in violation of RFC 1123, fail to record the return path of a message. Subsequent bounces are sent to an invented return path, typically the header From address. This behavior is a disaster for mailing-list messages, where the correct return path is the mailing list manager, and the From address is an innocent subscriber who has no way to remove bad addresses from the mailing list. Every mailer is responsible for using the correct return path.
- http://cr.yp.to/immhf/envelope.html.

Here is an excerpt from RFC 821 Simple Mail Transfer Protocol, the original SMTP specification, that has been made obsolete by RFC 2821.

When the receiver-SMTP makes the "final delivery" of a message it inserts at the beginning of the mail data a return path line. The return path line preserves the information in the from the MAIL command. Here, final delivery means the message leaves the SMTP world. Normally, this would mean it has been delivered to the destination user, but in some cases it may be further processed and transmitted by another mail system.

It is possible for the mailbox in the return path be different from the actual sender's mailbox, for example, if error responses are to be delivered a special error handling mailbox rather than the message senders.

The preceding two paragraphs imply that the final mail data will begin with a return path line, followed by one or more time stamp lines. These lines will be followed by the mail data header and body [2].

Here is an excerpt from the more current RFC 2821 Simple Mail Transfer Protocol specification, 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. Thisuse 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 it say that the e-mail must include a return-path header?

However, IMail does not include a return-path header, and instead, sticks the envelope sender in the mbox From_ line that isn't accessible to any program that doesn't have access to the raw mbox file (such as a client accessing the mail via POP3).

Here are example headers from an e-mail sent to test@cfpros.com, an account on an IMail server (notice that it doesn't begin with a Return-Path: header)...

Delivered-To: postmaster@squish Received: from mail.cfpros.com (65.218.70.100) by squish with POP3 for ; 26 Feb 2004 23:38:12 -0000 Received: from roam.unifiedmind.com [209.164.72.58] by wwip1 (SMTPD32-8.04) id A31185022E; Thu, 26 Feb 2004 17:36:49 -0600 Received: (qmail 21744 invoked from network); 26 Feb 2004 23:45:57 -0000 Received: from unknown (HELO jamesthornton.com) (james@66.143.167.86) by 0 with SMTP; 26 Feb 2004 23:45:57 -0000 Message-ID: <403E82C5.806@jamesthornton.com> Date: Thu, 26 Feb 2004 17:35:33 -0600 From: James Thornton User-Agent: Mozilla/5.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: test@cfpros.com Subject: test return path Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RCPT-TO: Status: R X-UIDL: 377596421

When I brought this to the attention of the IMail mailing list, I received this response:

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.

I don't agree with this since RFC 821 says, "When the receiver-SMTP makes the 'final delivery' of a message it inserts at the beginning of the mail data a return path line." Regardless, I persisted citing RFC 2821, "This use of return-path is required; mail systems MUST support it", but they replied saying that RFC 2821 is not a standard, SMTP RFCs have nothing to do with POP3, and do not dictate client behaviors. In spite of this, IMail claims to be RFC2821 compliant.

Another person on the IMail mailing list was confused by their statement that RFC 2821 is not a standard, and he sent e-mail to the RFC editors for clarification. Here is the reply he received from an RFC editor:

> I'm a little bit confused about the status of RFC 2821. On the list of > "Standards" http://www.rfc-editor.org/categories/rfc-standard.html it > has: > RFC0821 (STD0010) Simple Mail Transfer Protocol (Obsoleted by: RFC2821) > RFC1869 (STD0010) SMTP Service Extensions (Obsoleted by: RFC2821) > > But RFC 2821 isn't a Standard. It's on the list of "Proposed > Standards" http://www.rfc-editor.org/categories/rfc-proposed.html > RFC2821 Simple Mail Transfer Protocol > How can a Standard be obsoleted by anything other than another > Standard?

We are tempted to simply ask, "why not?", but that is probably not helpful.

There is a theoretical answer and a pragmatic one. The theoretical answer is that an implementor today should use RFC 2821 rather than RFC 821. On the other hand, RFC 2821 itself, while it is the desired source for implementors, has not itself reached the maturity to be a full Standard. This state of affairs arises because of the very, very dynamic nature of Internet protocol definitions, a historical fact.

RFC 821, like all RFCs, will stay forever in the RFC series, but it is no longer relevant to implementations once it is obsoleted. It is primarily of historical interest. [Some would say that its category should be changed to Historic, therefore, but such changes have not been the general practice in the past 20 years of the Internet standards process.]

The pragmatic observation is that the IETF very seldom carries a protocol specification beyond Proposed Standard. If you look into history, you will find that 821 became a Standard as a "legacy"; it pre-dated the Internet standards process, and never went through the formal progression Proposed Standard -> Draft Standard -> Standard. So 2821 may persist forever, until it is obsoleted by another Proposed Standard, without progressing. Or, it may be obsoleted by a progression to Draft Standard.

We hope this is clear.

RFC Editor

So RFC 2821 is the current specification, and it was published in April 2001. Furthermore, as one of the IMail responses indicated, "this was discussed briefly about two years ago on this list." 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 specifications.