Whenever we talk about doing SPF on the RFC2822 "From:", people counter
with the argument about mailing lists, which have different 2821 from
2822.
And it is true that there are many legitimate occasions when the 2822
"From:" differs from the 2821 return-path.
But the interesting thing is, those occasions tend to be recognizable.
PHB has been proposing on the MXCOMP list that if 2821 does not match
2822, the MUA should put up a red flag.
I think this is a brilliant idea, because it gives receivers something
they can comprehend: if it's a mailing list message, they don't mind the
red flag, but if it's claiming to be from eBay, they should be
suspicious.
They themselves know what mailing lists they're on, so that helps.
For purposes of fighting 2822 header spoofing / phishing /
impersonation, receivers now get multiple levels of accountability in
their email.
I propose that MUAs add two user-visible widgets:
- did SPF pass on 2821?
- does 2821 match 2822?
If SPF passes, display a little sign that says "SPF OK".
If 2821 matches 2822, display a little sign that says "HEADER MATCH".
The tests are independent.
But if both things pass, light them both up in green. This is the gold
standard.
As far as the user is concerned, the decision becomes easy: he becomes
aware that when there is no green, the provenance is suspect, but it may
well be a legitimate message anyway. The absence of green should be a
warning not to trust phishing attempts, but if it's just a mailing list
message it's okay to read it if the sign says "SPF OK".
Web-generated email might say "SPF OK" but won't get the gold standard
of "HEADER MATCH", and that's how it is.
Normal user-to-user email gets the gold standard if the sender has SPF.
How does this sound? This way we get to protect the 2822 From:, which
is something we all do want to do --- we just don't want to do it in a
way that breaks too much else.
So that's the basic idea. It needs a lot of tweaking but I think
there's something useful there.