Hi, PHB. Looking good.
On 4/2/2004 9:27 AM, Hallam-Baker, Phillip sent forth electrons to convey:
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.
Did you mean to say "the sender of the email"? (This would be in the
header of the sender's email.) Or did you mean to say "the domain
owner"? I think it should be part of the domain's published policy,
actually I think that's what you meant too.
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
Yes, this is a good start. i.e. two accept categories, and Make Sender:
have precedence over From:.
Perhaps there are other Headers worth checking (*Resent*?).
Actually, perhaps blanket allowing the check to be against Sender: instead of From: isn't a good idea.
My mail client (Mozilla/Tbird) doesn't display Sender:, unless I set it to
display all headers.
I'd guess most other clients do the same, but I haven't checked.
(If I send myself mail with Sender: but not From:, my MTA puts the 2821 FROM in
the From:.)
So mail with Sender:drevil(_at_)phisher(_dot_)dom and
From:support(_at_)paypal(_dot_)com will get through your test, AND look like
it's from PayPal!
Greeting card and Mailing list mail would be in the ACCEPT.UNVERIFIED bucket,
but I don't see a way to avoid that safely.
Wait, HOW's THIS:
ALWAYS lookup the From:'s profile. Reject if the domain in the From: says it
doesn't want to be in the From: (even if the Sender: checks out).
In pseudo code, with an attempt to match your formatting, which I'm not used to:
If the recipient supports RFC2822 verification it does this:
marid_from_profile = lookup_profile domain (from)
if (marid_from_profile.Verify-RFC2822 = True) { //From is protected?
if (is_consistent (source, marid_from_profile = True)) ACCEPT.VERIFIED
else REJECT.VERIFIED
}
else {
if (sender <> NULL) { //From: is not protected; check Sender:
marid_sender_profile = lookup_profile domain (sender)
if (marid_sender_profile.Verify-RFC2822 = True) //Sender is protected?
if (is_consistent (source, marid_sender_profile = True)) ACCEPT.UNVERIFIED
//<sic>
else REJECT.VERIFIED
//interesting.
else ACCEPT.UNVERIFIED //neither
protected
else ACCEPT.UNVERIFIED // no
Sender:
}
}
(Whew!)
Whaddya think?
You know, as I look at each of the 6 cases above, in the cases where the From:
is not protected, checking Sender: seems to not add much, but it does add
something, so it's just worth checking.
The case marked "interesting" may help protect mailing lists, which are
attractive targets for spammers to spoof. If all legit mailing lists published MARID
records, then perhaps mail that looked like it was from a mailing list and wasn't
reject.verified (and the mailing list's domain wasn't blacklisted) could be fairly safely
considered ham. WAIT-If the mailing list had NOT implemented SRS, Such email would
likely have been rejected at the 2821 stage, and if it HAD implemented SRS, the fact
that it wasn't reject.verified could be considered to have fairly confidently shown it to
be ham. Progress!
Do you get that the one marked <sic> is indeed UNverified, since the From: is
unverified?
What should is_consistent do exactly?
I think it should be renamed to is_good, as it's likely to evolve to a function
that not only checks if the domain is valid for a source IP, but also whether
that domain has a good reputation.
We agree on what's below.
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
Matthew