Julian Mehnle wrote:
I think "Checking other identities against the SPF records
defined in this memo is NOT RECOMMENDED" sounds awkward.
Yes, but the idea is still important. We know that "somebody"
is desperately trying to remove this statememet behind the
scenes. How often did you confirm the NOT RECOMMENDED in the
Council ? Meng promised that he will represent this resolution
in public, but what he really did was an attempt to cripple
Wayne's draft at the IESG.
All these "the IETF" were rubbish, one Andy Newton fighting for
Sender-ID isn't "the IETF", and Meng isn't "the SPF community".
So if you don't like my DEnglish - neither do I - here's the
same idea much shorter: s/SPF/v=spf1/
| Checking other identities against v=spf1 records is NOT
| RECOMMENDED because there are cases (e.g. Section 9.3) that
| are known to give incorrect results.
No more potential confusion with "spf2.0/pra NOT RECOOMENDED".
I don't acknowledge the legitimacy of any non-"v=spf1" SPF
records.
That's your decision. I acknowledge spf2.0/pra, spf2.0/mfrom,
spf2.0/submit, and (in theory) the undocumented spf2.0/helo.
Above all I acknowledge the one and only MARID result, PRA is
_not_ compatible with mfrom. I tried to change this somehow,
but the PRA faction refused to fix their weird algorithm with
its idiotic patent.
Minus minor details like positional modifiers v=spf1 is simply
the union of spf2.0/mfrom and a hypothetical spf2.0/helo.
If spf2.0/mfrom is known to be incompatible with spf2.0/pra,
then of course v=spf1 is also incompatible with spf2.0/pra.
Sure, there are cases where the policy is the same string, and
it is possible to say spf2.0/pra,mfrom (or spf2.0/mfrom,pra)
in these cases.
After MARID was closed there was still one chance to get this
effect with a simple op=pra. But the Sender-ID faction (Andy,
Meng, Jim) always wanted to get the complete installed v=spf1
base for their "patented" business interests.
So after they rejected all proposals to make it as compatible
as possible they now get what they deserve, it's incompatible.
Maybe some developers will be so kind to implement sp2.0/mfrom
in addition to v=spf1, so that users really wanting the effect
of a spf2.0/mfrom,pra can say so. But it's now more realistic
if they publish almost identical v=spf1 and spf2.0/pra records
like ebay.
Not our fault, all old op=pra and default-Sender ideas are now
in public archives, everybody can check this.
| Checking other identities against v=spf1 records is NOT
| RECOMMENDED.
Oops, okay, same idea. Any reason why want to get rid of the
pointer to 9.3 ? Wayne has explicitly added it to prevent the
next assault of the Sender-ID faction (i.e. Meng).
===============================================================
[2821 MUST]
There is no point in asserting (or even just assuming) that
most or all of the MTAs out there are fully compliant to RFC
2821. Some are, but others simply don't support source
routes, like it or not.
There's also no point in proposing that the "MUST accept" (and
then ignore) is bad, and that "reject" is a valid option for
"non-archaic" MTAs.
In essence SPF recreates the old source-route idea. The last
place where it should be ridiculed as archaic is the SPF spec.
===============================================================
[SPF policy != TXT policy]
If a client issues two DNS queries (TXT and SPF), it should
wait for both responses, and if they don't match, throw an
error
I'd never implement it this way, as soon as I get an answer I
use it and don't wait for any trouble in the form of a second
different answer. This SHOULD only delays the SPF evaluation.
Unless you have a "SPF cache layer" between SPF and DNS, then
this MAY make sense: A separate thread / process sending two
queries, first answer passed to SPF and cached, 2nd answer
compared with cached value, if different mark as invalid for
the shorter TTL. But that's no recipe for a straight forward
SPF implementation, so I still don't see the SHOULD.
Bye, Frank