wayne wrote:
doubt will be an obstacle. This thread is full of FUD.
I have to concur.
Yeah, I strongly agree also.
I don't. We've already seen cases where the v=spf1 record was fine,
but in combination with other records the TXT RR set was too big.
I think a large part of SPF's success over similar protocols like
RMX, DMP, FSV, etc. is the easy of creating SPF records.
Not easy enough. The "+mx" and "+a" could be implied, each policy
automatically has it. MTAs know how to handle MX queries. And if
there's no explicit "mx" mechanism anymore Doug's weirder SPF-DDoS
scenarios simply vanish.
The macro stuff is also more baroque than KISS. Per-user policies
aren't necessary, exp= is unnecessary, and the "exists" mechanism
is too general. SOFTFAIL could be replaced by op=testing.
Now you have some people promoting the use of spf2.0 records even
though the PRA has no technical advantages.
PRA is unnecessary. Ignoring irrelevant special cases passing PRA
routes should be always a superset of passing MAIL FROM routes.
With that a policy either enumerates all routes for PRA (including
all MAIL FROM routes) and can say op=pra, or it "only" enumerates
the MAIL FROM routes. The concept of a separate PRA "scope" makes
no sense, assuming that PRA makes sense at all - maybe outside of
SMTP after "something" (gateway) managed to delete the Return-Path.
Now you have some people promoting type99 SPF records even though
it has no technical advantages.
Of course it has, in theory. As soon as some other protocol abuses
TXT for its own purposes - because that's the most simple way around
the limitations of an MS API - there's not enough space. Anybody
wanting to use both protocols would be forced to deal with stuff
like "continuation records" (for SPF redirect=). And "continuaton
records" need more DNS queries.
This creates FUD and slows adoption.
That's just as it is, S-NAPTR didn't exist when SPF was invented.
Maybe we'd need a new kind of "T-NAPTR", with TXT at the leaves.
But of course not in the next 3+ years, later.
For SPFv1, I think we shouldn't touch it.
Sure. Julian's last 2*2 table was fine, it favours backwards
compatibility wrt error conditions. In essence it says "use the
TXT result for TempError if you query both SPF and TXT".
Frank
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735