In <000901c5aab5$962903c0$6c62fea9(_at_)ibmrkydk2ufvdd> "John Glube"
<jbglube(_at_)sympatico(_dot_)ca> writes:
How did this conflict arise? It arose after the closure of
MARID and prior to the filing of senderid-core-00.
Let's remember the scene. The open source community was up
in arms over the IPR disclosure by Microsoft.
That was not the only objection to SenderID and the PRA.
The objections to SenderID and the PRA include:
* The re-purposing of the Resent-* headers. The SenderID drafts
require forwarded email to add Resent-* headers, while RFC2822
explicitly says that forwarders are not supposed to add these
headers.
Since forwarders do not currently add Resent-* headers, it would
have been just as easy to create a new header for this purpose.
* The PRA can not distinguish between these two cases:
1) An email is sent to a mailing list, which adds a Sender: header,
and then the mailing lists sends it on to an email forwarder.
According to the SenderID documents, the forwarder needs to add
the Resent-* headers.
The resulting email will end up with both Sender: and Resent-*
headers.
2) Someone "bounces" an email (in the pine/elm/gnus sense of
re-sending the email) to a mailing list. As per RFC2822, these
MUAs correctly add the Resent-* headers to the email. The
mailing list then adds a Sender: header.
The resulting email will end up with both Sender: and Resent-*
headers.
The PRA has to give incorrect results in at least one of these cases.
* The re-purposing of the SPFv1 record, as outlined in this appeal.
* The PRA has a higher error rate than SPF since it fails not only in
cases where there is forwarding going on, but also on many mailing
lists.
* SenderID and the PRA is no more effective at stopping phishing than
classic SPF.
Simply displaying the "PRA PASS" result actually makes the phishing
problem worse, unless you also display the domain name that caused
the PASS result. Otherwise, phishers will put a service(_at_)paypal(_dot_)com
on the From: header, and add a "Resent-Sender: foo(_at_)phisher(_dot_)com",
and
the result will be a PRA PASS which looks like it came from paypal.
If you display the domain that caused the PRA PASS, you can just as
easily display the domain from the Return-Path and use SPF instead.
At this point, there are no advantages to using the PRA.
Of course, there was also:
* The PRA requires a patent license that is incompatible with several
open source licenses, representing a significant number of MTA and
spam-filter software currently deployed. It also requires
commercial companies to inform Microsoft when they plan to create a
product that uses the PRA.
And finally, there are people who objected to both SPF and SenderID
because:
* Both SPF and SenderID break forwarding.
* Both SPF and SenderID require everyone to either send email through
designated MTAs, or to have special exceptions created often
requiring specialized software. This is known as the "working from
home user", "roaming user" or "traveling salesman" problem.
* Both SPF and SenderID break greating-card sites and the "send a news
article to a friend" sites.
The licensing issue was most certainly *NOT* the only cause for the
closing of the MARID WG.
All in all, the PRA has lots of disadvantages compared with SPF and no
advantages. (Other than support by MS, that is.)
Except for the cases of the re-purposing of SPFv1 records and the
re-purposing of the Resent-* headers, I think the market can deal with
the problems with the PRA.
Mr. Wong, over the strong objections of many within the SPF
community, went ahead and negotiated an arrangement that
allowed for the backward compatibility of PRA
authentication with spfv1 records. [2]
You can't "negotiate" over technical problems. No one can create
"backward compatibility" by decree.
Further to this arrangement:
* The Lentczner draft for spfv1, which only supported mail
from authentication and the Lyon draft for spf2, which
supported both mail from and PRA authentication were filed
with the IESG.
* Both drafts flowed from MARID.
You have the timeline slightly messed up here. The work Mark
Lentczner did during MARID was not about SPFv1, it was about SenderID.
Mark created an SPF-classic draft *after* MARID was shut down. There
is some dispute about whether this was intended to be part of the call
for individual submissions made when MARID ended, but it was never
intended to be used as the basis for the SenderID drafts.
The fact that the lentczner-spf-00 I-D did not include support for the
HELO identity was one of many incompatibilities with earlier SPF
specifications and deployed SPF implementations. It was due to the
large number of incompatibilities that the lentczner-spf-00 draft never
reached a rough consensus level of support within the SPF community.
* Microsoft published an SPF wizard which supported the
publication of spfv1 records, subject to the need of
publishers to be satisfied their spfv1 records could be
used for both mail from and PRA authentication.
It should be noted that the SPF wizard that Microsoft created produced
completely invalid SPF records until shortly before the FTC Email Auth
Summit, which was long after MARID closed. The number of records with
these tell-tail errors is actually fairly small, indicating just how
little MS backing for publishing SPF records actually had.
-wayne