The IESG decided:
while we have found merit in Julian Mehnle's technical
concerns, we will not change our decision to publish the
draft as an Experimental RFC without change to its technical
content.
The IESG did consider this conflict in its original
discussions, and that is one of the reasons why we crafted
the original IESG note to be included in these documents,
which highlights that there are concerns about using these
mechanisms in tandem.
That's beside the point. Of course "consenting adults" can use
"spf2.0/mfrom,pra", and that's semantically almost the same as
"v=spf1" plus an identical "spf2.0/pra" policy. There are no
technical issues with using these mechanisms in tandem for all
senders explicitly wishing to participate in both experiments.
The issue are senders _not_ wishing to participate in the later
PRA experiment: "v=spf1" is semantically almost the same as
"spf2.0/mfrom" _without_ "spf2.0/pra".
That's what the v=spf1 spec. says with its "NOT RECOMMENDED" in
chapter 2.4. It simply reflects what all v=spf1 specifications
and implementations did since 2003.
It is quite clear that this conflict would not be acceptable
for a standards track specification.
It's also unacceptale for a standards organization with a bare
minimum of ethical and engineering principles.
document the different approaches as they were considered in
the MARID working group.
The MARID WG came to the conclusion that PRA (spf2.0/pra) is in
fact so different from SPF (v=spf1 or spf2.0/mfrom) that they
should be clearly separated. That was the last MARID decision
before this WG was dissolved unilaterally by Mr. Hardie.
[he = Julian]
he requested that we modify draft-lyon-senderid-core to
address the conflict.
Yes, backed by the SPF community and more than 200 signatures
<http://old.openspf.org/cgi-bin/openspf_pledge.cgi>. This does
not include several competent voices who don't like v=spf1, but
still agree that (ab)using v=spf1 for PRA without the explicit
consent of the v=spf1 participants is an ethical and technical
nightmare.
his proposed modification amounted to a substantive technical
change.
That's not the case. His proposal affects _four characters_ in
a chapter about the alleged spf2.0 "backwards" compatibility:
Instead of 'treat v=spf1 like spf2.0/mfrom,pra' this should be
'treat v=spf1 like spf2.0/mfrom'.
The IESG did not consider this an appropriate action to take
in this case.
Well, you are wrong, and everybody can see it. If one draft
says "SHOULD do x", and another draft says "SHOULD NOT do x",
then something has to give.
Depending on the content of the record, this may mean that
Sender-ID heuristics would be applied incorrectly to a
message.
This does _not_ depend on the content of the v=spf1 record. It
depends on a PRA being identical to the MAIL FROM. Which isn't
the case for a significant portion of all mails.
Participants publishing SPF experiment DNS records should
consider the advice given in section 3.4 of RFC XXXX
(draft-lyon-senderid-core) and may wish to publish both
v=spf1 and v=spf2.0 records to avoid the conflict.
There's no such thing as "v=spf2.0 records". This "advice" is
completely bogus, there are more than a million v=spf1 records,
and it will take years to migrate this installed base to use
the new SPF RR.
For this migration period the best they can do is to publish
both SPF and TXT records, "v=spf1" or "spf2.0". Asking the
participants of the older "experiment" to publish four records
instead of two won't fly, let alone anytime soon.
Besides, since when favours the IESG "opt-out" for experiments
with non-consenting participants ?
we hope that this augmented IESG note will address his
concerns.
I seriously doubt it. 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