James Couzens wrote:
Whilst I can see Wayne's line of thought for most of the
items on the list, the vast majority seem to equate to
feature creep
His "validating evaluation" is a good feature, because Mark's
idea to document "common mistakes" in a FAQ (and be done with
it) unfortunately doesn't work well.
It's no serious problem if you don't implement it anytime soon,
but it's still a nice feature I'd like to creep into the draft.
It's very irritating for all of us if the same sender policy
sometimes works (or appears to work), and at other times it
fails (apparently). Where FAIL includes deleting legit mails
(worst case only, but still).
( http://libspf.org/files/spf-draft-200405.txt ) which is
what libSPF currently resembles as far as I can tell is only
in need of some minor changes, I really don't think much
needs to be added.
It's IMO better to build on draft-lentczner with its new SPF RR,
and add some missing stuff from what you or Wayne have. The
SPF RR is a "sine qua non" for the IETF procedure.
In practice Phill is probably right, the (ab)use of TXT will
stay for some time, but his idea to ignore the IETF and start a
new standards organization is megalomaniac. We can still try
this stunt after the IESG rejected a perfectly sound SPF draft
without good reasons.
If they try to delay the process it won't work, because SPF is
obviously a good idea. The longer they try to delay it, the
more TXT records are used. That's not in the interest of DNS,
they are in a dilemma there. Trying to delay SPF until whoever
pulls the IESG strings have commercial FUSSPs also won't work.
Perhaps others could do the same and inform me of this
effort.
My collection of SPF related stuff minus Wayne's pre-releases
<http://purl.net/xyzzy/home/test>
In your copy it's "MAY zone cut" with "match_subdomains=yes".
That's bad, because MAY is the same as MAYBE NOT. It should
be MUST or at least SHOULD, always, not only with a op=sub or
whatever. Otherwise domain owners are forced to publish a
policy for each and every subdomain if they want a reliable
solution. With wildcards and its oddities.
The "zone cut" is IMHO the only critical feature, whatever we
do, it won't be 100% compatible with all existing tools and
policies. OTOH it doesn't delete legit mails whatever we do,
that's where I draw the line (and "Sender ID" is beyond it ;-)
Bye, Frank