David MacQuigg wrote:
I'm not smart enough to tell if draft-otis is FUD or real
worries.
Pure FUD. The usual tactics of first mixing SPF and Sender-ID,
then get unsubstantiated hype from spf.pobox and other pages,
and finally prove that Sender-ID is not really good as anti-
phishing scheme, and SPF is even worse. Never mind that SPF
never claimed to be anti-phishing, it's anti-forgery, but the
MAPS-CSV-BATV-gang styling itself as "MIPA" uses always the
same chains of pseudo-arguments.
Another chain of pseudo-arguments used by MIPA:
Obviously -all doesn't work well for "traditional forwarding"
to 3rd parties. Obviously that's a feature, in fact it's the
only real feature of SPF, either test SPF at the MX, or don't
test it at all.
But the MIPA-gang simply assumes that it's a bug (as soon as
you read "bounces-to" instead of "Return-Path" or "MAIL FROM"
you can be sure to have met a MIPA-fan). Therefore they say
that SPF makes only sense without FAIL, because otherwise some
receivers with forwarding to 3rd parties could have a problem.
Next they prove that SPF minus FAIL isn't very useful, spammers
can always set up a throw-away domain with a dummy policy to
get a PASS. Therefore a PASS from unknown strangers is in fact
useless. Therefore SPF is useless, and besides BATV could get
almost all bogus bounces independent of the receiver.
This chain of arguments is bogus. And because Dave / John /
Doug / etc. are not stupid they do this deliberately, shame on
them. Of course SPF minus FAIL is rather useless, Like a car
without wheels, so what ?
CSV does the authentication check in one query, using an SRV
record.
Up to six queries for John's pseudo-zone-cut (right to left but
excl. TLDs to protect the root servers).
Seems like we need an "SPF-Lite", with nothing but IP blocks.
That would be RMX, but it's now too late to change the winning
team. If you want "SPF-Lite" you can have it today: Ignore
all policies with a / mx / ptr / exists / include / redirect.
IMHO that's not clever, but ignoring all policies without the
chance of a FAIL could make sense: SPF minus FAIL is rather
useless.
Can SPF3 have *fewer* features than SPF1?
Of course, it should. The exp= is more than baroque, it's near
to ridiculous. Who cares about the "personal reasons" of the
publisher for a FAIL ? If we want I18N for why.html then let's
just do it.
Okay, in theory you could do smart things with exp=, e.g. offer
a form where the poor sender can fix the sender policy which
caused a FAIL. But in practice, who needs this ? Bye, Frank