what will happen is a whole rash of ad-hoc schemes will be tried
with varying effectiveness. We will end up with the uncertainty
that you are concerned about.
A particularly good point in that email. (We don't want
anyone coding
anything like if From: != MAIL FROM, trash it, period.
Let's get something good out before the lousy stuff becomes any more
popular.
What I propose here is a flag Verify-RFC2822 which the sender of the email
MAY set to be true or false.
If the recipient supports RFC2822 verification it:
1) if sender <> NULL then query-domain = domain (sender)
else query-domain = domain (from)
2) profile = lookup_profile (query-domain)
3) if
(profile.Verify-RFC2822 = False) ACCEPT.UNVERIFIED
((profile.Verify-RFC2822 = True) AND
(is_consistent (source, profile = True)) ACCEPT.VERIFIED
(profile.Verify-RFC2822 = True) AND
(is_consistent (source, profile) = False)) REJECT.VERIFIED
What this means is that the sender can advise the recipient that:
1) They are a likely target for impersonation attack and
2) All legitimate mail from the domain is sent through the
stated channels.
By setting Verify-RFC2822 = True
The implications on the infrastructure are
1) If the flag is not set,
Recipients are discouraged from verifying the RFC2822 headers
as the sender does not undertake to make sure they are correct.
2) If the flag is set
The Sender has to make sure that all legitimate senders from
the domain have email configurations that route messages
through an authorized relay server
The infrastructure implications are not likely to be significant for
likely targets of phishing fraud or other significant impersonation
attacks. Banks and payment processors usually have pretty strict
requirements for regulatory reasons any way.
There would be an impact for greeting card sites and the like
that did not use the Sender: header to inform the user that the
message was sent on behalf of the purported sender. I really do
not think that is at all unreasonable.
Phill