>>>>> "Daniel" == Daniel Quinlan <[EMAIL PROTECTED]> writes:
Daniel> When the MTA is delivering to the list processor, I think
Daniel> it's a big stretch actually "left the SMTP environment".
Yes. I described the behaviour as "not unreasonable" because
pragmatically the MTA probably doesn't know that. It just knows it's
delivered the mail to a program, and doesn't know that that program
happens to be a list processor. I'm not saying this is desirable
according to the RFCs, just that this is what I would expect given the
typical implementation of MTAs and list processors and their typical
interaction.
Daniel> That doesn't really sound like an okay to behave badly.
Daniel> ;-)
No. But it's not a prohibition, so gmx.net certainly shouldn't bounce
mail as a result of apache.org's software behaving this way.
Daniel> It seems like the right thing here is for gmx.net to
Daniel> rewrite and the Apache list processor to remove the
Daniel> Return-Path: header.
The right thing for gmx.net to do as far as SMTP-time SPF checks go is
for it to follow the SPF spec and base its SPF checks on the MAIL FROM
argument rather than the value of the pre-existing Return-Path header.
As far as what gmx.net should do with the Return-Path header. If it's
performing final delivery, it MUST add its own Return-Path header (and
MAY remove any pre-existing ones). If its just forwarding the message
on then it MUST NOT modify any existing Return-Path header. See
RFC2821 section 4.4.
We're in agreement that the list processor SHOULD remove the
pre-existing Return-Path header from the message.
In any case, as far as SPF checks go, SpamAssassin is getting it
right; gmx.net is broken...
-roy
