From: Hallam-Baker, Phillip
Sent: September 22, 2004 11:06 PM
I have spent two years on this, I don't believe that anyone
has the right to simply say that its over because they have
made a decision. Who elected them? Who do they hold
themselves accountable to?
The answer is certainly not us and certainly not the
Internet users.
I appreciate and respect the frustration level, but I don't
believe this process is over by a long country mile.
Like everyone else, I would like to have seen a formal
standard come out of this process.
At the same time, a number of issues presented potential
stumbling blocks:
* The technical issue surrounding breaking of mail
forwarding by "mailfrom" and "core/pra" checking which to
my understanding are not resolved with Submitter.
At least with "core/pra" checking there seems to be a
conflict with the use of re-sent headers and how these are
categorized in RFC 2822.
I understand this issue was noted early, but also see the
last jabber session for a discussion of this issue with
Pete Resnick.
http://www.xmpp.org/ietf-logs/marid(_at_)ietf(_dot_)xmpp(_dot_)org/2004-09-20.html
* The concerns expressed surrounding the usefulness of
"mailfrom" and "core/pra" checking as a basis for
reputation and accreditation.
* The lack of an operations and security review by
graybeards of "mailfrom" and "core/pra" checking.
* The IPR claim (s) and the draft patent license.
On this point, many have suggested the WG should have dealt
with the IPR issue much earlier in the process.
In fairness, time was needed to allow the behind the scenes
negotiations over the draft patent license to proceed as
far as they could.
Besides, the maximum point of leverage came after the
Apache Foundation announced it could not support deployment
of Sender-ID as originally put forward, due to problems
with the patent license.
In an effort to salvage the work done, the WG chairs
decided to move forward with an SPF record syntax which
supported multiple scopes, starting with "mailfrom" and
"pra" checking.
In turn, immediately prior to expiry of last call in
response to a direct question, MS confirmed it had no IPR
claim on "mailfrom" checking.
We are not aware of any Microsoft IPR claim related to
spoof checking of MAIL FROM. Therefore, the Sender ID
license is irrelevent for checking MAIL FROM.
There is also the following statement:
As I stated above, we are not aware of any Microsoft IPR
claims on MAIL FROM checking, so our license is not
relevent. So, to be as clear as I can, if you're
implementing spoof checks of both PRA and MAIL FROM under
the framework described in Core (and our patent application
is granted) then you would need a license for the PRA check
but not the MAIL FROM check. If you are implementing spoof
checking of MAIL FROM and _not_ PRA, we have no IPR claims,
and no license to offer.
http://www.imc.org/ietf-mxcomp/mail-archive/msg04655.html
The apparent IPR problems? First we had the revelation of
the full breadth and scope of the patent applications last
week.
Then we had a press statement by an MS press person in an
article in Internetnews on Monday. Jim Wagner, who wrote
this piece stated:
Microsoft would not comment on specifics of the patent
application but a spokesperson sent an e-mail stating:
The SPF technical alternative is just now becoming a real
focus for the IETF. It is premature for the standards
participants to disclose any IP they may own related to
SPF. If SPF continues to work its way through the process,
there will likely be a point where Microsoft and others
will [be] asked to identify any essential IP claims and
Microsoft will follow the IETF guidelines for disclosure at
that time.
http://www.internetnews.com/dev-news/article.php/3409971
This statement arguably implies Microsoft may have an IPR
claim on "mailfrom" checking, despite the limited extent of
the original IPR claim and the prior unequivocal statements
denying any IPR claim.
As to CSV, CSA and DNA the proposal for ehelo/helo checking
does not break mail forwarding. However:
* Apart from shear UBE volumes, the big problems presently
are 'bounces' when a domain is spoofed and financial losses
suffered from phishing attacks.
As originally presented, CSV, CSA and DNA do not directly
deal with these two pressing issues.
The BATV proposal attempts to respond to the first problem.
http://brandenburg.com/CSV/draft-levine-mass-batv-00.html#I-D.ema
il-arch
The Mail Policy Records proposal endeavours to help to deal
with the second problem.
http://www.imc.org/ietf-mxcomp/mail-archive/msg03341.html
I write attempt and endeavour because we have no field
testing, nor a security/operations review of these
revisions.
However, see the following analysis:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03364.html
* To respond to UBE volumes, CSV, CSA and DNA are heavily
reliant on implementation of reputation and accreditation
services.
Although UBE volumes are horrific, the "sexy" issues are
dealing with spoofing and particularly phishing attacks.
Hence "pra" checking and "Caller-ID" checking at the mail
user level.
How best to proceed?
* A unified approach, at least on the basis of both
"mailfrom" and "core/pra" checking appears to be in
technical trouble.
The consensus concerning the incompatibility of "core/pra"
checking with RFC 2822 seems to compel the rejection of
"core/pra" as an IETF backed experimental proposal.
* The broad scope of the MS patent claims and the inability
of MS to craft a patent license which both protects its
interest and is fully compatible with the various open
source licenses applicable to existing MTA software cries
out for a response, if the open source community wishes to
continue with "mail from" checking on the basis of SPF.
My concern is that unless steps are taken to thwart the
patent claims, if "mailfrom" checking based on SPF gains
experimental status, as an IETF backed proposal, despite
clear statements to the contrary, the suits within MS may
decide to place an IPR claim against this proposal.
As to MS, if one goes to the MS sponsored wizard site, you
will note this statement:
This wizard is in beta and is intended to illustrate what
SPF records will look like and the ease of creating them.
We anticipate possible changes to the final format by the
IETF. As such, records are subject to change until the
standard has been finalized and approved. You should not
publish the record that is generated until this tool is
finalized.
http://www.anti-spamtools.org/SenderIDEmailPolicyTool/Default.asp
x
Translation. Don't use this wizard to publish a record. MS
needs IETF approval for "core/pra" checking to proceed.
The result? The IETF/IESG continues to have leverage to
compel MS to back off on its broad patent claims, should
people wish to get IETF experimental approval for SPF based
"mailfrom" checking without a license and "core/pra"
checking with a license.
Whether this is what the open source community wants is
another question. My own view is if folks try and push
forward for IETF experimental approval of SPF based
"mailfrom" checking alone, this will die on the table along
with "core/pra" checking.
* Ideally we need one record which allows for mail channel
authentication, affords protection against spoof generated
bounces, can be reliably used by reputation and
accreditation services, does not break forwarding and is
not IPR encumbered.
* There is one large ISP which has publicly stated it will
continue to run with SPF for beta testing, but is very
interested in the new "CSV."
http://www.imc.org/ietf-mxcomp/mail-archive/msg04935.html
* As to message authentication, to quote from the same post:
"the best way to secure the 822 FROM address is a content
signing approach."
Of course this is why this particular ISP withdrew its
support for "core" and "pra" checking. Why go through the
whole exercise of getting everyone to implement header
rewriting schemes, if we know there is a better way for
message authentication.
So, yes what has happened with the shutting down of MARID
is unfortunate. But, sender authentication is far from over.
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.766 / Virus Database: 513 - Release Date: 17/09/2004