Now that the internet draft for spfv1 has been filed, I
believe it is appropriate to discuss what to do about spfv2
and sender-id.
Some on this list would like to see spfv2 allow for
multiple scopes including pra.
From the last go around, the clear consensus was that the
spfv1 protocol should not consider pra checking.
My present views on spfv2:
* Until Microsoft confirms it has no intellectual property
rights claim against mail from, ehelo/helo and IP address
checking and Microsoft's draft patent license is amended so
that it is fully compatible with the Open Standards
Alliance model, my recommendation is that we should
politely say to Microsoft, we are unable to support the pra
scope in spfv2 until these matters are resolved.
As a side note, although representatives of Microsoft's
made it clear during MARID that Microsoft did not have an
IPR claim against "mail from, ehelo/helo and IP address
checking," the submission filed by Microsoft with the FTC
is saying in essence:
"while we acknowledge the statements made during MARID, the
full scope of our IPR claims won't be known until our
patent applications are dealt with by the USPTO."
(Please note, I am paraphrasing.)
The result is we continue to operate under a potential
shadow on this issue and it is for this reason, I for one
believe Microsoft can't have it both ways.
On the draft patent license, the submission filed by
Microsoft with the FTC makes it apparent that for now,
Microsoft has no interest in having any discussions
concerning the draft patent license.
* To avoid getting caught up in any attack on Microsoft's
submissions over the intellectual property rights and draft
patent license questions, I suggest we put to Microsoft
that it would be best we "de-couple" pra checking from spf
entirely.
How should we do this? My suggestion is that we put to
Microsoft representatives:
* We understand Microsoft has no interest in mail from
checking and would prefer to move ahead only with pra
checking.
* We will draft a protocol for publishing an email policy
record utilizing some of the ideas in spfv2, but we won't
use the pre-fix spf or v=spf and the record will only
support pra checking. We will call this record sid1.0. Any
draft, will be reviewed by the spf discuss list before
submission and will be drafted in such a way so as to have
no negative impact whatsoever on the sender policy
framework.
* We will continue to proceed forward with the existing SPF
experimental proposal supporting mail from checking. At the
same time, Microsoft can move forward with a experimental
proposal, utilizing the protocol we draft that supports pra
checking.
* As to the next version of SPF, when we are ready, we have
told the Area Directorate, we will submit the appropriate
drafts. If you would like SPF to support PRA checking in
version 2, the steps which Microsoft must take are clear.
Until then, we plan to move ahead with fleshing out
EHELO/HELO checking, working on signed envelope sender
concepts, while also carrying out work on a submitter
concept which supports MAIL FROM checking and allows MUA's
to display the authentication results.
This allows Mark (and Meng) to meet any obligation
involving drafting a protocol which supports pra checking,
while making it crystal clear, SPF will not support pra
checking until Microsoft satisfactorily resolves matters.
Want to proceed? Then Microsoft, you can deal with and
respond to all the forces opposed to PRA checking because
of the patent applications and the form of draft patent
license. However, since we don't support your stance, we
feel it best you go forward with those folks who are
willing to support your licensing stance.
Some might say, but what if Microsoft insists. Insists on
what? In my view all bets were off when Microsoft filed its
submission with the FTC in support of Sender ID.
http://www.ftc.gov/os/comments/emailauthentication - see
comment #26
In particular read pages 2 -3 of the submission where
Microsoft states:
|"One of these proposals, "Sender 1D" is based on a
|combination of Microsoft's "Caller ID For Email" and the
|Sender Policy Framework ("SPF"). Sender ID involves three
|steps:
|
|1. E-mail senders (of all sizes) publish the Internet
|protocol ("IP") addresses of their outbound e-mail servers
|in the Domain Name System ("DNS") according to tbe
|"Sender-ID specification."
|
|2. Recipient e-mail systems examine each message to
|determine the purported responsible domain.
|
|3. Recipient e-mail systems search the DNS for the list of
|the outbound IP addresses of that domain and then check
|whether the IP address from which the message was received
|is on that list. Once widespread deployment is achieved, if
|no match is found, the message is not authenticated and has
|likely been spoofed. During the initial phase of
|deployment, such authentication failure would likely be
|included in filtering technologies and algorithms designed
|to detect spam."
This document makes it clear as to Microsoft's intentions.
(As an aside, this is the only reference to SPF throughout
the document and there is no reference to mail from
checking at all, despite the statements made in the Spiezle
letter.)
Once this position is put forward, people can then simply
get on with the business of moving ahead.
* I appreciate some will argue there are lots of benefits
of simply moving ahead with Microsoft. I appreciate this
position, however if that were the case, mail from and pra
would have made it through last call without MARID being
shut down, with mailfrom and pra checking now on the
standards track. However, that is not the case. Instead
what happened is the whole process "blew up," over an
attempt by Microsoft to simply take over the whole thing.
At the same time, since Microsoft is not yet supporting
Sender ID, folks are running to the SPF help list asking
what do I do about Sender ID records? Interesting ...
I also suggest:
* Once a consensus is reached, some form of charter be put
forward, so that the work and discussion can remain focused
on the topics at hand.
Okay, my 2 cents worth on this contentious subject.
John
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.776 / Virus Database: 523 - Release Date: 12/10/2004