william(at)elan.net wrote:
[MUA]
it can either derive PRA email address from multiple headers
or it might as well just take email address from single
Return-Path header (which one do you think is simpler?).
Return-Path is not only simpler but more important it's also
correct. RfC 3834 has a recipe for mails without Return-Path:
| A Personal or Group responder SHOULD NOT deliver a response
| to any address other than that in the Return-Path field, even
| if the Return-Path field is missing. It is better to fix the
| problem with the mail delivery system than to rely on
| heuristics to guess the appropriate destination of the
| response. Such heuristics have been known to cause problems
| in the past.
ok for such MUA to use currently published v=spf1 records.
Your new PRA = Return-Path is compatible with all published
v=spf1 policies, RfC 2476, RfC 3834, draft-lentczner, etc.
add new SPF policy identifer that will let some (but not
necessarily all) senders indicate if their emails are such
that their RFC2821 MAIL-FROM address should be the same as
either RFC2822 "From:" or RFC2822 "Sender:".
Excellent idea. While you're at it you could also add another
modifier for Scott's HARDPASS (= "nobody else using the same
mailers is in the position to forge my address")
This part is very important for banks and other financial
institutions that want to use SPF to protect against
phishing
And unlike Sender-ID your idea is clear, simple, and works as
expected. You need CAVEATs for some mailing lists relying on
Errors-To: instead of Sender:, and for users of well-behaved
MSAs opting out of RfC 2476 8.1 "MAY add Sender:".
Now MUAs can check SPF record for Return-Path address
They need a "Mailhost" configuration like SpamCop to find the
relevant Received: header with the "border" IP of the sender.
It's not trivial, but possible (as SpamCop has demonstrated).
v=spf1 ip4:192.168.0.0/24 eh=sender,from -all
Oops, so this could be also eh=errors-to,sender,from to avoid
FPs with a mailing list like SYMPA ? Nice idea, but it does
not cover the Resent-cases, or does it ?
How about "eh=1" for users where one of the Resent/From/Sender
headers _always_ matches (in the order defined by RfC 822), and
no eh=1 modifier otherwise ?
Bye, Frank