Pekka Savola wrote:
1) make no changes to the spec. The spec (assumably)
documents the existing behaviour, even if it is
conflicting.
SPF (both v=spf1 and spf2.0, there is no "v=pf2.0") allows
to log DNS queries. That's documented in the v=spf1 draft:
With SPF's "exists:"-mechanism it's possible to log when
somebody tries to evaluate the policy.
Result of this experiment (last state that I've heard of):
Absolutely nobody evaluates "spf2.0/pra". This "opt-out"
strategy from the PRA-experiment does not work.
Adding an "IESG note" to the v=spf1 spec. how participants
of this "experiment" could "opt-out" from the PRA-experiment
by adding dummy PRA-records, where this in practice doesn't
work, is pointless.
For SPF-"experiment" read about 1.000.000 published policies
with about 10 independent interoperable implementations, and
for PRA-experiment read "nobody really uses or wants PRA".
No joke, I offered a simple PRA-"opt-in" modifier for v=spf1,
and the precise number of interested v=spf1 users was _zero_ :
<http://purl.net/xyzzy/home/test/draft-spf-6-3-options-09.txt>
So in practice nobody wants PRA, and almost nobody bothers to
implement spf2.0/pra, "opt-out" by dummy PRA records is doomed.
But there's still the danger that somebody implements a post-
SMTP PRA-check abusing v=spf1 records. An ignorant somebody
thinking that a PRA-PASS or a PRA-FAIL indicated by a MUA is
cute even if it's wrong.
At this point he has already violated several SHOULD NOT and
won't care about details like "this PRA-result is a bad PRG".
But unfortunately it will _apparently_ work as expected for
most mails. Users will believe that a PRA-FAIL is spam, and
a PRA-PASS is no phish. Getting it wrong in those cases
where the PRA is not the same as the Return-Path.
the IESG decided that accurate documentation of the running
code is more important than documenting something that does
not exist, and maybe never will exist.
If there is running spf2.0/pra code it apparently fails to
honour the dummy "opt-out" records. And there's of course no
chance to add those dummy spf2.0 records to about 1.000.000
published v=spf1 policies in this decade:
SPF (both v=spf1 and spf2.0) is designed that you can forget
a published policy as soon as it's correct, and as long as
you don't change your (sending) mail setup.
Publishers of v=spf1 policies in 2004/05 have no reason to
find an obscure "IESG note" asking them to "opt out" from the
unrelated PRA-experiment of 2005/06.
Maybe it won't work even if they'd find and try it, see above.
Bye, 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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com