Roy Badami <[EMAIL PROTECTED]> writes:
> According to RFC2821, Return-Path is only added when doing final
> delivery. What has happenened is that the MTA at apache.org has (not
> unreasonably) added a Return-Path header when delivering the message
> to the list processor.
Well, RFC 2821 says:
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. Here, final delivery means the message
has left the SMTP environment. Normally, this would mean it had been
delivered to the destination user or an associated mail drop, but in
some cases it may be further processed and transmitted by another
mail system.
When the MTA is delivering to the list processor, I think it's a big
stretch actually "left the SMTP environment". If it's using SMTP as the
connection protocol, then it's wholly incorrect. Also note that this is
definitely not normal usage since it hasn't been delivered to the end
point.
I suppose you could selectively interpret the MTA role and selectively
interpret what the list processor should do, but the combination of the
two interpretations is too much, resulting in a message being sent with
an incorrect return-path.
> It would be completely wrong for the list to send the mail out with a
> Return-Path of owner-spamassassin-users; that header would only be
> added when the MTA at gmx.net performs final delivery.
>
> RFC2821 says that a message SHOULD NOT be sent containing a
> Return-Path header. So what the list processing software should
> ideally have done is removed the existing Return-Path header prior to
> resending. But since it is a SHOULD NOT rather than a MUST NOT, the
> list processor is within its rights to behave as it does.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
That doesn't really sound like an okay to behave badly. ;-)
It seems like the right thing here is for gmx.net to rewrite and the
Apache list processor to remove the Return-Path: header.
Daniel
--
Daniel Quinlan anti-spam (SpamAssassin), Linux,
http://www.pathname.com/~quinlan/ and open source consulting
