Gaven Henderson wrote:
the archives don't support searches
Maybe check out GMaNe's search engine in some weeks (not now,
it's replaced by a better engine, and there are the usual
issues like dying hard disks, some misssing packages in a new
installation, etc., Murphy and his gang at work again... ;-)
<http://news.gmane.org/index.php?prefix=gmane.mail.spam.spf>
Does anybody else think that allowing for non-exclusive
(?all) SPF records completely kills the goal of Sender
Policy Framework?
Not completely, you can do white listing based on SPF PASS.
And not all policies with ?all have no -whatever (FAIL).
But if you see a pure "v=spf1 ?all" then it's in fact the
same as NONE, that's also the definition of ? (NEUTRAL),
and the default (without any [-~+]all or redirect=).
OTOH the spec. says "SHOULD use -all". Publishers need a
good reason to use policies without -all. And there are
good reasons, even -whatever +all can make sense.
With non-exclusive SPF records, MTAs are left with the same
determination.
That's not necessarily the case, it depends on what you find
_before_ the ?all. Example:
"v=spf1 ip4:0.0.0.0/1 -ip4:128.0.0.0/1 ?all"
That policy says that the IPs 0.0.0.0 .. 127.255.255.255 PASS
and all other IPs FAIl. The ?all is never reached. Somewhat
bogus, "v=spf1 ip4:0.0.0.0/1 -all" has the same effect. But
there are many variations where it's not that obvious, e.g.
"v=spf1 -exists:{ir}.blacklist.example ?all"
All IPs on blacklist.example FAIL, for others you get no clue.
if an SPF record allows for a soft fail, then it does not
allow for a hard fail.
SOFTFAIL is mainly for testing, as a permanent solution it's
a bad idea (SOFTFAIL might end up in "suspicious" folders at
the receiver, where it's automatically deleted later).
where do anonymous senders fit in?
They'd use a MAIL FROM:admin(_at_)mixmaster(_dot_)example> or similar
after a long chain of mixes promising to be FBI-resistant ;-)
SPF changes absolutely nothing wrt _real_ anon-mail.
After all, SMTP authentication can be used to verify all
stages of a domains internal routing without having to
publish anything on the internet.
Sure, but "somewhere" is the point where an MTA on your side
talks to an MX of the receiver. Exactly there, especially not
later, SPF works. All you have to do is to enumerate the IPs
of all your border MTAs - or some bigger set of IPs, but a bit
more precise than +all would be nice.
As you said SPF policies without a _chance_ for a FAIL are not
convincing (but not completely useless, a PASS is still good
enough as "permission" to bounce / challenge (whatever it does,
it won't hurt an innocent bystander) or with white lists.
Non-exclusive SPF records make SPF a 'half-ass' solution.
You're free to ignore what you don't like. SPF is voluntary
for all participants.
.
Spammers and hackers are smart and aggressive people, if you
provide them an inch, they will take a mile.
Of course. But if they forge a MAIL FROM resulting in a FAIL
they are more aggressive than smart. That's the idea of SPF.
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com