At 05:36 AM 3/31/2005 +0200, Frank Ellerman wrote:
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.
SPF has left itself open to this criticism by not having a clear policy on
forwarding. Forwarders will ask 1) How do I know which name to
authenticate? and 2) How do I pass the result downstream? There needs to
be a simple, widely accepted answer to these questions or SPF will fail.
<snip rebuttal of faulty arguments against SPF>
> 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).
Good point. The SRV record is one query, but we certainly have to include
all the queries necessary to "drill down" to where the SRV record is
actually kept. So if rr.com were to use CSV, they would need to set up
subdomains with one or two servers each, and names like
mail05.austin.rr.com, or maybe mail0537.rr.com. This is where it might
make sense to have a recursive slave server at rr.com with cached records
from the entire domain.
Looks like the ability of SPF to list many IP blocks instead of just a few
single IPs is a substantial advantage.
> 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.
The problem is we need more than just receivers *ignoring* these
complexities. We need senders *avoiding* them when they write their SPF
records. I don't think its too late for SPF to start a migration
process. If the next release has a one-query "defense mode" for receivers
and a strong recommendation for senders to use the compiler and simplify
their records, we may reduce the temptation for DNS abuse enough that it
never happens. If it does happen, there will be strong pressure on the few
domains with expensive SPF records, and not so much blame on SPF.
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
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *