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 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf