Fresh from the FUD factory:
draft-newton-maawg-spf-considerations-00
Sigh... It's really not Andy's fault if he's forced to explain
the "zone cut" as a major difference between "classic SPF" and
"original SPF". It's the same problem on the ASRG list or on
spf-devel.
WTH is going on with the SPF Council and Wayne's draft -01 ?
[Sender-ID]
| The syntax of the record can either be the SPF syntax
| specified by original SPF (Section 2.1.1) (identified by the
| "v=spf1" version identifier) or a slightly different SPF
| syntax (identified by the "spf2.0" identifier).
That's of course hogwash, v=spf1 doesn't work with PRA, period.
| 3.1 User Agents
SPF is almost useless as anti-phishing tool, and PRA isn't much
better. Now that's true. Never mind that SPF never claimed to
be an anti-phishing tool.
| 3.3 Publisher's Intent
That chapter is wrong. First of all v=spf1 is *incompatible*
with PRA no matter what Meng, Jim, the RfC editor, Andy, Phil,
or others say.
NOT RECOMMENDED is really not good enough, SHALL NOT is clear.
| a non-committal SPF record of "spf2.0/mfrom ?all" will signal
| that all PRA checking against this domain will have unknown
| results.
No, see draft-lyon-senderid-core-00 (3.4):
: if the information in a "v=spf1" record is not correct for a
: PRA check, administrators SHOULD publish
[...]
: an "spf2.0/pra ?all" record indicating that the result of a
: PRA chek is explicitly inconclusive.
If fact "spf2.0/pra" is enough to opt-out from this PRA abuse,
5 bytes saved. And certainly _not_ "spf2.0/mfrom ?all", what
a monstrous idea.
Of course v=spf1 publishers won't do this, they just follow
the spec., v=spf1 is _never_ tested against PRA because this
_must_ cause havoc, especially because there are so few FPs.
And the author of this text should know this. Andy was it who
asked Mark to create an spf2.0/mfrom scope and I-D different
from spf2.0/pra exactly for this reason. Mark did this, see
<http://purl.net/xyzzy/home/test/> draft-ietf-marid-* (but not
the 2005 CSV texts pretending to be from the defunct MARID WG)
I'll never trust anybody involved in the MARID disaster, never.
| 6.1 Mechanisms Lookup
Again the worst case of 111 DNS queries (1 TXT, 10 MX, each MX
with 10 names). That's a _theoretical_ limit, one q=mx reply
normally includes the corresponding IPs. And then this worst
case degenerates into 11 queries. Make it 12 for q=spf before
q=txt. And it's a DDoS attack scenario, real sender policies
are not that complex.
The 20 seconds limit is something I'm strongly opposed to, but
Wayne never answered. I hope that nobody implements it - the
DNS timeout is good enough, SPF does not need its own timer.
| receivers and senders may need to reach bilateral transaction
| agreements that bypass SPF in cases where SPF records cannot
| be formulated with more tolerable values.
Yes, that's a good idea.
| 6.2 Zone Cut Issues
Sigh, see above, that's really not Andy's fault. The reason
given to remove the "zone cut" is the most convincing I've seen
so far. I'd still say that it's the problem of the sender to
get his DNS right, but discussing this with clueless "uplinks"
(left to right in a FQDN) could be a royal PITA.
| If no adverse problems are found after a sufficient period of
| time, change the SPF record so that it makes the most
| agressive assertion (i.e. end it in "-all")
That part (6.3.1) should be copied to any SPF FAQ or draft.
Stopping precisely _before_ this statement:
| Due to unknowable forwarding relationships with the Internet
| email infrastructure, it may not be possible for all domains
| to publish SPF records with an agressive assertion.
Forwarding is the business of the receiver, not the sender, and
SPF is a _sender_ policy framework.
| 6.3.3 Use of the 'include' Mechanism
Andy claims that "classic" SPF is here incompatible with the
"original" SPF behavious: For "classic" it's an error if the
included record is not found.
Andy's definition of "original" matches what I'd consider as
"original": draft-mengwong-spf-01 And in this text I read:
: However, if the new query returns none, error, or unknown,
: then processing of the entire SPF query stops immediately
: and returns the error result.
..................^^^^^
Oh yes, the table below this clear statement got it wrong and
proposes to return "unknown", it's just a very old and buggy
spec., that's why there were one - two - three more attempts
to get a proper draft (marid, lentczner, schlitt). "Classic":
: TempError | throw TempError
: PermError | throw PermError
: None | throw PermError
Wayne uses 550 5.5.2 if repeated attempts from exactly the same
sender with the same broken sender policy are useless. That's
the definition of 5xx in RfC 2821.
"Lentczner" (cited by lyon-senderid-core-00) == "classic".
Finally draft-ietf-marid-protocol-03 (sounds familiar ?), same
as "classic". The stupid table in the "original" draft was a
BUG, as far as I'm concerned. And BTW it's not the only BUG in
the "original" draft.
| 7.2 Use of Other Authentication Schemes
[...]
| v=spf1 +all
A chapter about imaginary benefits of "+all", but FUD about
v=spf1 vs. PRA, FUD about "include", not one word about the
real purpose of spf2.0/mfrom or v=spf1 (rejecting forgeries).
Bye, Frank (posted in spf-discuss)