I just finished reading a reasonably significant portion of the relevant
comments in the ietf-mxcomp archives:
http://www.imc.org/ietf-mxcomp/mail-archive/threads.html
IMHO, the two "successful" arguments for continuing with SenderID that must be
refuted are:
1. Companies of importance, e.g. AOL, will have no problem with the SenderID
license.
2. Anti-forgery with SenderID will gain adoption much faster with Microsoft's
influence and help.
IMHO, the rest of the arguments for SenderID were already reasonably refuted.
Here is my opinion on how to refute these:
1. A standard should be implementable by all, or at least most. Even though
for example AOL claims they can implement as a receiver without IPR problems,
they and we all should IMHO also be concerned about implementation of other
receivers, because AOL and all of us are also a senders of e-mail.
2. But under Microsoft's control with the added leverage of being endorsed as
public standard, which is IMHO not the spirit of internet standards. In
general I think it is not wise, nor consistent with the RFCs under which IETF
supposedly operates, to create "internet standards" which give leverage to one
competitor over **ALL** others, by "standardizing" on one competitor's license.
The larger question though is the greater good helped more than hurt? IMHO,
anti-forgery (especially per-domain anti-forgery) is not a complete solution to
spam, and thus doing any action that would could stifle the diversity of
competition in anti-spam, is very dangerous to the greater good.
AccuSpam is an example of a anti-spam receiver which may not be able to
implement SenderID if it requires signing a license with Microsoft, because it
is possible that Microsoft may one day view AccuSpam as a competitor to some
anti-spam product from Microsoft and AccuSpam might not want to give Microsoft
the leverage of an executed license.
Regards,
Shelby Moore