In <yf2oenpztjy(_dot_)fsf(_at_)proton(_dot_)pathname(_dot_)com> Daniel Quinlan
<quinlan(_at_)pathname(_dot_)com> writes:
In other words, SPF doesn't solve joe-jobs except for sites that *do*
SPF checks. Deploying SPF only prevents _receivers_ from sending or
acting on joe-jobs.
Agreed, but this is still useful. While it is best to try to reject
email during the SMTP session, that isn't always possible. SPF helps
reduce the damage done to innocient victimes of forgery in those
cases.
Senders have to wait until all (or nearly all) of
the world's receivers have deployed SPF.
I suspect that this really isn't going to be the case. There really
aren't that many large-scale spammers, spamware authors aand
virus/worm authors. Once the number of domains publish and MTAs check
SPF reach a certain level, these few hundred people will start
to adapt.
They will either choose domains that don't publish SPF records, thus
eliminating forgery for those that do, or they will use domains that
they have permission to use, thus eliminatin forgery for everyone.
The latter will, in many cases, be easier for spammers and worms.
In the mean time, a pass from an SPF check could increase the
reliability of things like SpamAssassin's auto-whitelist. (Does SA
use both the 2821 and 2822 froms in the AWL? I know that DCC's
whitelisting functions support both.) A fail from an SPF check will
be a high (but not absolute) indicator of spam.
-wayne