|Internet Business Consultant|
|Home||Blog||Bio||Projects||Contact||Latest Blog (new site): How to Get to Genius|
IMail: No Return-Path Header or Envelope Sender as Per RFC 821/2821
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.
Here is an excerpt from RFC 821 Simple Mail Transfer Protocol, the original SMTP specification, that has been made obsolete by RFC 2821.
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 email@example.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 (22.214.171.124) by squish with POP3 for
When I brought this to the attention of the IMail mailing list, I received this response:
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?
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.
Services: Internet Consultant
|Electric Speed: Linux Administrator|