Team-
I am encouraged by what I have seen in the last week or so, both on the MARID
list and at the Email Technology Conference (ETC) (which I will write a
summary of later today).
If it turns out that SPF is a great tool that can be used for other email
identities, not just Return-Path, then it is well-poised to be extremely
relevant in a post-MARID world. I strongly believe that the core of SPF can
be applied to PRA easily, and with a bit of care to From: and Sender: also.
(We already know it works very well for HELO too.)
Here is my take on it. There are some identities that naturally bond quite
strongly to IP, such as HELO, PRA, and MAIL FROM+SRS. There are other
identities that don't bond strongly to IP, like From: and Sender:, but if you
do check them and they happen to Pass, that's very good info.
In my previous post "Defining the Layers" I tried to classify the various
identities into groups, depending on where in the life cycle of a mail message
they are likely to change and where they will remain consistent. This also
suggests whether those identites bind strongly to IP as well.
Layer 0: HELO and PTR
These should bind strongly to IP. Unfortunately there are cases where the
HELO is a fake name, or the PTR is missing, or both. At this stage we are
looking for a FAIL, in order to spot obvious forgeries like "HELO
microsoft.com" or HELO with the receiver's domain as many viruses do. This
catches some of the "low-hanging fruits" of the forgery world. By itself a
PASS result here doesn't validate the whole email, it's just the bare minimum
check for an MTA.
Layer 1: PRA and MAIL FROM+SRS (and eventually SUBMITTER)
These should normally bind strongly to IP as well. This validates the "last
submission" or "last forwarding hop". This tells you *something* about the
message, even if it's just the identity of the forwarder. (If you have a
forwarding address like gconnor(_at_)pobox(_dot_)com then the PRA is often your
own
address) It may just be the last submission, but at least it's a domain name,
and a starting point for reporting abuse without IP lookups.
Layer 2: From: and Sender:
These bond weakly to IP because the message could have gone through forwarding
steps to reach you. But, if you do check them and they happen to PASS, this
is excellent information. (This is sort of the opposite of Layer 0: here we
are looking for a PASS and ignoring FAIL, and for HELO we are looking for FAIL
and ignoring PASS.) However, the authorization could have other info that
doesn't require IP, like domainkeys, in which case it is OK to check and
reject.
Here's another point... In the discussions about PRA/SUBMITTER it was
suggested that we should only accept forwards from places we trust... after
all, if we set up the forwarding relationship, we already trust the forwarder
to accept and relay our email. So, in the cases were Layer 1 PRA does not
equal Layer 2 From:/Sender:, we should be suspicious of PRA's we don't trust.
Conversely, if it is a PRA that we DO trust, perhaps we can accept whatever
SPF results THEY recorded when THEY scanned the message (this is what I
described as "Bootstrapping Trust"). For example, if all my mail is forwarded
and the PRA is always myself (e.g. gconnor(_at_)pobox(_dot_)com) then perhaps I
can set
up my MUA to recognize this and always accept the PRA as authentic, and then
the next-level authorization becomes available.
Anyway... these are some ideas to think about. I will be excited to see what
comes out of the MARID working group... it looks like we are in a good
position overall.
Later
gregc
--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org
Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"