In
<1099718696(_dot_)7185(_dot_)64(_dot_)camel(_at_)antitrust(_dot_)6o4(_dot_)ca>
James Couzens <jcouzens(_at_)6o4(_dot_)ca> writes:
On Fri, 2004-11-05 at 23:14 -0600, wayne wrote:
before I head off to bed, I would like to make one recommendation:
Change the URL to something else so that the main OpenSPF page can be
used as a home page.
Again, I *highly* recommend that the URL of this web page be changed.
The original request to Meng asked for a web page that MS could link
to. While I kind of doubt that, due to the less than positive
comments, MS will choose to link to this web page, it still makes
sense to move it.
While it is tempting to throw in every problem with SenderID into a
position statement, I think we need to keep it short. I think it has
already become too long and we should now be looking at cutting stuff
out and tightening up the language.
: Positions of the SPF Community in regards "Sender ID"
:
: SPF's developers and users welcome proposals that will truely help
: clean up the current email mess. Many SPF developer's and users
s/current email mess/current problems with email forgery/
s/developer's/developers/
: consider that Microsoft's SenderID proposal is technically unsound and
: undermines the progress already begun by SPF. SPF development and
: deployment predate Microsoft's entry into the field and have achieved
: significant success to date. SenderID, in its most recent form,
: appears likely to interfere with the correct function and deployment
: of SPF.
:
: One of the reasons that the Internet is so tremendously successful is
: that its core technologies have been open for use and development by
: all. Non-commercial developers write much vital Internet software,
: including the mail transfer agent (MTA) programs that handle the
: majority of the world's email.
In order to keep the focus on email, I suggest replacing these two
sentences with:
Email on the Internet has used primarily freely available software and
open standards since the late 1970s and, even today, a large majority
of all mail servers run Free or Open Source software.
: Microsoft's licensing position
: regarding SenderID makes it difficult or impossible for many of these
: authors to incorporate SenderID.
Replace with:
Microsoft's patent license for SenderID does include royalty-free
terms, but other terms of the license makes it difficult or impossible
for many of these widely used mail servers to incorporate SenderID.
MS has frequently used the royalty-free part as a red-herring, so we
need to address it.
: If SenderID were widely deployed, the
: license issue would create a barrier to open development of Internet
: infrastructure software that has not previously existed. SPF on the
: other hand has been made freely available to all, including Microsoft,
: with no restrictions whatsoever.
:
: Using SenderID _REQUIRES_ SPF
:
: SPF is an independent "domain based" authentication protocol and is
: the direct result of efforts exerted by an open group independent of
: financial motive. [...]
s/independent of financial motive./of developers./
Financial motives is not a bad thing, and quite a few people have
them. (e.g. Meng, Hector, the Schlossnagles, etc.)
: Sender-ID requires SPF in order to be implemented.
: Sender-ID is a superset, or a higher level protocol which attempts to
: address the "forwarding problem" where responsible domains no longer
: have an association with the sender IP address thus causing a
: potential for false positives.
:
: Sender-ID shares scope with another superset or higher level protocol
: designed to solve the exact same problem, namely SRS (Sender Rewriting
: Scheme). SRS it should be noted is free of IPR claims and has been
: available since February of 2004.
I don't understand what Hector was getting at with this paragraph.
SenderID doesn't do any better of a job at forwarding than SPF.
Forwarders will have to do something for either.
I suggest dropping this.
: Microsoft's patent license for SenderID is incompatible with far too
: large a percentage of deployed MTAs for it to become a standard
: (de-jure or de-facto).
:
: "PRA" (Purported Responsible Address) as it is implemented within
: SenderID, has many technical problems that make it unsuitable for use
: in the real world. Whilst this technical aspect was not the sole
: contributor to the demise of the MARID working group it played a key
: role in acting as a major stumbling block for many.*
:
: "What threw the big wrench in was Microsoft's IPR," says Doug Otis, a
: working group participant and "The non-transferable license made it
: onerous for open source community to share code. The wind went out of
: the sails at that point," says Doug Otis, a working group participant.
I still don't like the phrasing of this quote from Doug Otis.
Actually, I would probably deleted it just to shorten up the text.
: The PRA algorithm used in SenderID will not protect the From: header
: when phishing is going on. Phishers will certainly adapt to making
: the Resent-Sender: header pass PRA checks. When that happens, From:,
: Sender: and Resent-From: headers are left unverified by PRA and can
: still be forged. So, the PRA only protects From: when there is no
: need to protect it and fails to protect it when needed. (Note: "SPF
: Classic" has essentially the same weakness against phishing, but makes
: no claim that it provides superior phishing protection.)
:
: PRA gives false positives (fails) on all the same things that SPF
s/false positives (fails)/incorrect results (false positives)/
: does, but also fails on mailing lists, moderated newsgroups, most MSAs
: enforcing submission rights (RFC 2476) without adding a corresponding
: "Sender:" header, and other MTAs adding incorrect "Sender:" headers.
:
: From what information is available, the general consensus is that,
: since mail coming from mailing lists is far more common than mail
: coming from forwarders, this means that the PRA will have an error
: rate of at least 10 and maybe up to 1000 times as high as "SPF
: Classic".
This paragraph should be below the one that talks about the lack of
real world testing. Readers will understand why we can't pin down the
SenderID error rate.
: SenderID re-purposes the v=spf1 records. This will cause failures in
: cases where deployed SPF records currently work. In some cases, those
: failures can be fixed by changing records, in others (e.g. SES
: exists:), they can't. Where SenderID breaks the function of existing
: v=spf1 records, domain owners will only learn of it when legitimate
: mail is not delivered. SPF record publishers made their records
: public with the expectation that they would be used with the SPF
: algorithm. SenderID puts those records to a different, possibly
: incompatible use, without any consent from the publishers.
:
: When SenderID was under consideration by the MARID task group, there
: was never any acceptance of the idea that SenderID would reuse v=spf1
: records. Microsoft, appeared to agree that SenderID would require its
: own records. Since the time MARID failed to advance the SenderID
: proposal to the IETF for further consideration, Microsoft has proposed
: this reuse of v=spf1 records on their own.
I suggest deleting this paragraph. There *was* wide acceptance of
reusing v=spf1 records in the MARID group, but new records were
mandated at IETF-60. While I think the IETF will probably again
mandate new records, I think that is much more of an IETF position
than an SPF community position.
: PRA has had very limited deployment and testing, making it far riskier
: than "SPF Classic", which has been in testing in every major MTA
: (qmail, Sendmail, Postfix, Courier, Exim, and yes, even Exchange)
: since the beginning of this year.
Move this paragraph up above the one that talks about the error rate.
: PRA requires a use of the Resent-* headers that many people believe is
: inconsistent with the use defined in RFC2822. Almost(?) no one
: currently uses these headers for either mailing lists or forwarding.
:
: It appears that the only reason the Resent-* headers are used instead
: of a new PRA-specific header is that, if a new header were to be used,
: it would render obvious the fact that this is a significant change to
: the current email environment.
Ok, those are my comments.
What else should be snipped?
-wayne