Julian Mehnle wrote:
I'd be happy to read any advice you have when I wake up.
Here's an attempt with a short line of arguments:
Deployment of SPF began in early 2004. It was designed to
check the MAIL FROM (2821-From) Return-Path in SMTP, not
any 2822-header fields like PRA.
Inspired by Stuart's article here: The _titles_ of Meng's
and Mark's drafts alone show this.
Last before MARID draft-mengwong-spf-01.txt
A Convention to Describe Hosts Authorized to Send SMTP Traffic
First after MARID draft-lentczner-spf-00
Authorizing Use of Domains in MAIL FROM
MARID decided that using existing v=spf1 policies for PRA
cannot work, evidence Meng's v=marid article.
For a substantial portion of mail (some say 80%, pointer to
one of Hector's article stating this) MAIL FROM and PRA are
different, as explained in (pointer to old appeal).
The v=spf1 spec. draft-schlitt-spf-classic-02 explains why
checking other identities (not limited to PRA) against v=spf1
policies is NOT RECOMMENDED.
More than a million v=spf1 policies have been published
under this assumption since early 2004.
In chapter 3.4 senderid-core claims that v=spf1 SHOULD be
handled like sp2.0/mfrom,pra (i.e. PRA == MAIL FROM routes).
This is incorrect, v=spf1 is almost the same as spf2.0/mfrom
but can be very different from spf2.0/pra.
Participants in the v=spf1 "experiment" (quotes intended)
are not necessarily interested to participate in the later
(fall 2004) PRA-experiment.
They're not necessarily interested to publish dummy sp2.0/pra
policies to "opt-out" from PRA as explained in senderid-core.
PRA is known to be cumbersome and violate Internet standards
(pointer to IESG reply wrt William's appeal). It's not
feasible (sp?) to upgrade all existing v=spf1 policies with
dummy PRA opt-out records.
The IESG note (pointer to IESG reply wrt your appeal) simply
reiterates the "opt-out" recipe in senderid-core. Many
participants in the v=spf1 "experiment" do not wish to be
non-voluntary participants in the PRA-scheme with their mail.
They consider this as unethical and violating even the lowest
conceivable (sp?) engineering standards. It would cause the
loss of legit mails.
For the IAB the more tricky point of bogus PRA PASS results
with their potential damage is probably a bit too esoterical.
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