Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

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