On Wed, 27 Oct 2004, Greg Connor wrote:
For one thing, this has to do with MSA policies and SPF is pretty focused
on the MTA. For another, the "best practices" in these cases are still in
the process of being clarified and are not well understood by most ISPs,
let alone practiced widely.
SPF provides policy records for domains used in email parameters by EITHER
MSAs or MTAs. I note that currently MSAs are the ones that set RFC2821
MAIL-FROM and then submit the email and rarely if ever does initial ISP
server actually change it (and if it would be new domain).
The purpose of the SPF record is thus to provide policies of the email
agents on the network originating the email with given MAIL FROM and
entering policy records in regards to how the same parameter corresponds
to another if all agents on the network support it is ok.
Probably the best thing to do for SPF1 users is to write up a "best
practices statement" that says what RFC2476 expects MSAs to do, and to
encourage senders to follow it, as Part 2 of a two-part anti-forgery
campaign, where SPF1 is Part 1. Make it clear to people that SPF narrows
the forgery playing field down from "anywhere in the world" to "your ISP"
and it is up to the ISP to close the local loopholes. Suggest to people
that if their ISP doesn't comply, that they should give the ISP a ? instead
of + when referring to them by include, ptr, etc. (Though creative use of
SES and a magic DNS server might still upgrade the questionable-sourced
messages to a "+" status)
I would also suggest that we add "MSA auth best practices and standards" to
the list of "things to do" for SPF2, because it seems to fit at least
tangentially with the idea of scopes and wider policy statements.
If we write BCP it would be for both SPF1 & SPF2 establishing that users
should use their home ISP mail server for submitting email when roaming, etc.
(Now I might be in the minority here, so I am willing to be overridden, but
I'm guessing that more people will hesitate to add anything to SPF1,
however harmless...)
Like having it interprted in the specific 2822 MSA content without even
any specific record allowing for it (i.e. use of SPF1 by SenderID)?
Most of us, myself included, will not be in a position to benefit from
this as our providers do not yet meet these standards. But for the few
providers who take the trouble to really do it right, meaning enforcing
submission rights on both 2821 and 2822 identities and providing SMTP
AUTH so their customers can always send from their own servers, why can't
we give them a small benefit and some encouragement in the form of extra
joe-job protection that doesn't cost the rest of us anything?
Again, it's not that I'm objecting to the idea per se, just that I think it
adds complexity without adding huge value. It's totally important for ISPs
to comply, and to state that they comply, but giving them an automated way
to make that statement is not needed that badly right now, and I don't
think SPF1 is the best way to do it.
I disagree
Now if we were talking SPF2 I would be totally all for it :)
I'm not sure what the deal with SPF2 is because it appears Microsoft already
introduced it without us agreeing on details and making it be the same as SPF1
In any case, modifiers can be introduced into SPF1 (as separate document)
just find and "SPF2" would then put all together in one spec if necessary.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/