Although I have more than once made my opinion clear, I am now doing
this in a format that will hopefully meat with the last call
requirements and as such will be taken into account by the chairs.
While I do believe SenderID would be a step in the right direction, I
don't think it's an appropriate standard. I say this because I have
doubts about the legal repercusions implementation for me would have, as
well as doubts about the technical issues. Senderid is not the only
proposal, and surely not technologically superior to the other
proposals. In particular, I think Unified-SPF is far more promising than
senderid.
I have serious problems with the legal entanglements that cloud over
SenderID. I am an active developer for sendmail patches for one of the
popular SPF-Classic and SRS implementations, and I'm looking into other
MTA's that do not have an compiled-in spf implementation yet.
As an implementor, I presumably would have to sign the license to be
able to implement SenderID. I have studied the license, read the
discussions on this list and other lists, and still am not exactly sure
what my rights are and what microsoft's rights are. What I do know, is
that microsoft will use their large funds to squash any serious
competition.
A particular example of how microsoft does so is a recent ruling by the
Dutch court against Lindows Inc (http://zdnet.com.com/2100-1104_2-5151087.html)
. Although I am not all in favour of how
Lindows (or Linspire as it is now called) does business, I'm quite
appauled that microsoft has succesfully blocked the sale of linspire
in The Netherlands. This is only one of the incidents which make me
doubt that microsoft will not mis-use their licenses and patents for the
same purpose: squashing competition.
Having a party sign the license might give microsoft the power to revoke
the license if competition is becoming more than a very minor annoyance. The
anology of 'signing a pact with the devil' seems appropriate enough to me: you
get the immediate benefit of being able to implement senderid, but you don't
know what bad things hang over your head until it's time for microsoft to 'cash
in on the pact'.
It is already common knowledge that microsoft's initial reaction to spf was
to sue it to a silent death. Furthermore, microsoft is even now
claiming sender-id as their own invention, not acknowledging the IETF,
not acknowledging Meng Weng Wong.
Eg, http://www.infoworld.com/article/04/08/31/HNspammerstudy_1.html
claims that 'New technology for identifying the sender of e-mail
messages has not been widely adopted despite backing from software giant
Microsoft Corp.'. It is to me obvious this refers to SPF, which is
being deployed despite microsoft's attempts to frustrate development.
I can get more url's by just browsing back in the archive of the
spf-discuss list, where skepticism about microsoft's intentions is not
considered an 'emotional reaction'. Let the facts speak for themselves.
I have doubts about all of this, however if I have to find a lawyer to
clear this up for me, the fun is off. I will not be able to develop for
senderid. If that is the case, I will also not publish senderid records
on my own domains or the domains of customers and neither will I install
software that checks senderid records.
Note that this is not a rant against microsoft, this is a enumeration of
a number of facts which have helped form my opinion about microsoft. It
seems foolish to ignore these (and all the other) facts, even though
we've been promised all this past behaviour is not representative of how
microsoft will act in regard to senderid. I have seen _no_ evidence that
microsoft will not continue the trend it has been setting for years.
Furthermore, the fact that senderid does not protect me against 2821
forgery is also a barrier to me deploying the standard.
Now there are two roads that could be taken from that observation:
senderid could be extended by 2821 checking, or a 2821 checking proposal
can be extended to also check 2822 entities. The former is, for reasons
stated above, not my preffered option. The latter, however, is
promising. SPF-Classic is already widely deployed, and extension of
SPF-Classic to 2822 entities by ways of Unified-SPF seems very
promising.
I truly hope that
1. The IETF/MARID will come to it's senses and consider the overwhelming
amount of statements that senderid is undeployable except by the
fortune-500 companies, or at the least has a serious problem with
development and distribution outside the world of commercial,
closed-source software.
2. Development of SPF-Unified will be continued by Meng Weng Wong and
Mark Lentczner, and will be picked up by the ever-growing spf community.
I for one, considering myself a member of that community, will put my
resources into making Unified SPF a reality if senderid continues to be
surrounded by all the fog.
Koen Martens
--
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/