In
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200410/0599.html
and other similar posts Meng argues that:
1. We need to way to allow MUA email software to verify email based on
SPF records
2. PRA (RFC2822 headers) domain authorizations records will
always be the same as MAIL-FROM data
And makes a conclusion from there that we thus should support PRA as
that is right way to authenticate RFC2822 information and should allow
them to share the same SPF record.
I do not agree with above position but I do agree that some form of RFC2822
authentication is needed. Based on some of the things Meng said i would
like to propose a simpler alternative to PRA that likely will not break
any existing standards. At the same time I believe it will satisfy needs
of company like Microsoft that wants to do MUA checking based on email
headers to protect against phishing and will allow to reuse "v=spf1"
records for both just like Meng & Microsoft want to do.
First let me point out that almost all delivery agents add Return-Path
header to the top of the message as way to save the value of RFC2821
MAIL FROM. That means that in theory MUA clients know last RFC2821
mail-from value and if they wants to can do SPF check (assuming it can
figure out what SMTP client ip to check on based on herecy data in
Received headers which I personally think is not good enough for that).
Since Meng and Microsoft (and previously Mark) argue that SPF records for
MAIL-FROM and PRA would be the same in almost all cases and they argue
that mail system has a fairly equivalent choice that it can either check
PRA or check MAIl-FROM, it seems that the same choice is present for MUA
and 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?).
And as you notice by using address from Return-Path, i.e. RFC2821 MAIL
FROM address the MUA would not be violating currently proposed SPF drafts
(draft-lentczner-spf-00 or draft-schlitt-spf.00pre1.txt) and so its
ok for such MUA to use currently published v=spf1 records.
Second I part of the idea is to 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:". This part is very important for banks
and other financial institutions that want to use SPF to protect against
phishing and all of them as far as I know already do send emails that have
same RFC2822 From: address as RFC2821 MAIL FROM.
Now MUAs can check SPF record for Return-Path address and if they find this
new policy identifier they can check to make sure that the same address
appears in either Sender or From address and make sure that address is
displayed to the user as part of the email original address (and if its
not the same, then email can be classifed as potential forgery).
For new policy record, I propose to use a modifier "equivalent-headers="
(to make it shorter, I'll use "eh=") with typical record being like this:
v=spf1 ip4:192.168.0.0/24 eh=sender,from -all
Now I suspect that for many domains they do not want to have global domain
policy like that and may want to specify it only for certain "from"
addresses, so it might be appropriate in some way to allow this modifier
to use macro and redirect to some other record, but I have not come up
with good syntax for that yet (though I'm sure the people who are more
familiar with SPF macros can suggest something...).
Let me know what you think and if this seems like a workable solution both
to people who support classic-spf and for companies that make MUAs and want
a solution against phishing. Also please examine the above for possible
violations of existing standards (though I think unlike PRA its ok).
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/