Jeff,
Thanks for pointing out that the MS site was updated on
August 20, 2004.
It is interesting to note that the overview is urging folks
to publish an SPF record by October 1, 2004 and to become
fully Sender-ID compliant by December 31, 2004
The SPF record which MS is urging folks to publish is
v=spf2.0/pra in text in the DNS IN file.
This is fine, but it puts people into the position of
having to publish two version strings in the DNS IN file.
One version string allows receivers to check the SMTP Mail
From address. The other version string allows receivers to
check the PRA.
There has been much discussion over the last 3 weeks on the
MARID mailing list and the SPF discuss list since the MARID
face to face on August 4.
Three issues have been raised:
(1) Why change the version string?
(2) The lack of a malformed SMTP mail from check at the
data stage in the marid-draft core. This allows spammers to
avoid detection, permitting well crafted spam and phishing
messages to end up in recipient's mail boxes.
(3) The lack of an SMTP mail from check in the absence of
PRA at the data stage in the marid-draft core.
It has been strongly urged that doing this check using the
SPF protocol would reduce spoofing (joe-jobbing) and
minimize false positives, without creating any significant
additional problems by way of unwanted back scatter.
A technical concern was also raised mid week that Sender-ID
does not meet the requirements of the MARID charter.
It has been suggested Sender-ID should be rejected for this
reason.
Some have disputed the validity of the technical analysis
put forward by Chris Haynes who raised the objection.
Others have suggested there is no need for Sender-ID to
fully meet the requirements of the MARID charter.
However, at present the objection remains.
A representative of MS has acknowledged the legitimacy of
concern (2) and suggested a Best Current Practice document
be prepared to address only this issue.
However, to date the only response on issue (3) from
representatives of MS has been to point out there is a
"semantic difference between the 2821 MAIL FROM address and
the 2822 headers."
Unfortunately, this does not deal with the concern.
It seems some supporters of Sender ID are prepared to
consider a proposal which at least addresses issues (2) and
(3), as long as Sender-ID continues forward.
However, for some reason, although representatives of MS
are prepared to put forward a proposal which allows for a
malformed SMTP MAIL FROM address check in the absence of
PRA at the data stage, being issue (2) by way of a BCP,
there is a high degree of reluctance to go further and
recommend an SMPT MAIL FROM address check using the SPF
draft protocol in the absence of PRA at the data stage,
being issue (3) by way of a BCP.
It might be helpful if those who were present at the
meetings at Redmond on August 12 would urge MS to
reconsider its stance.
As to working out an arrangement of having one version
string instead of two in TXT in the DNS IN file, which
could be used for SPF classic and Sender-ID, this would be
nice.
Certainly it would be helpful if MS were to come forward
with a compromise on this point.
I can't speak for Chris Haynes. However, if MS were to come
forward with a good faith BCP which meets the concerns
raised, it would be logical for Chris to withdraw his
objection.
But, again looking at the situation logically, without such
an acceptable BCP, there is no reason for Chris to withdraw
his objection and the present stand off continues.
I add that Hadmut Danisch, the designer of RMX has raised
an IPR claim with respect to marid draft core - 03. To
date, there has been no response to Hadmut's concern as he
is away from his desk until 24.08.04.
Again, I can't speak for Hadmut. However, if Hadmut saw
that Chris's technical concerns were satisfied, he was
given recognition in marid-draft core and any other
objections of Hadmut were satisfied, it seems logical he
would withdraw his IPR claim.
If not this is another potential impediment preventing
Sender-ID from moving ahead.
Where does this leave the Internet community at large?
In my opinion, reading the present state of play on the
MARID mailing list, if the large organizations which
presently support Sender-ID being Tumbleweed, Trustee,
IronPort, Symantec and the members of the ESPC want the
participation of the SPF community, I suggest MS has to be
persuaded to move forward and fully meet the concerns
raised in a good faith fashion.
If not, who knows what will happen.
Please note this does not deal with the MS IPR and license
issue.
Depending on the positions taken by MS on the noted issues
on 23.08.04, along with the license form itself, we may see
either:
* Another storm of protest next week, or
* The SPF community simply deciding "shag it," who needs
Sender-ID and the IETF. Let's continue to support and
perfect SPF.
In my view the later is the most likely outcome if MS
continues on the present path.
What happens to Sender-ID? I suspect the resounding answer
from most in the SPF community will be who cares.
This potential split into two solitudes is most unfortunate
and is not good for the industry as a whole. Sender
authentication, reputation and accreditation requires a
co-operative effort.
I would simply urge people to use their best efforts to
resolve matters in the best interest of the whole community.
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.737 / Virus Database: 491 - Release Date: 11/08/2004