ietf-mxcomp
[Top] [All Lists]

DEPLOY: Significant Sender ID license issues at universities

2004-09-01 14:38:25

I am a professor at New York University, and also the author of an
open-source SMTP server called Mail Avenger.  I'd like Mail Avenger to
support whatever standard emerges from the MARID working group, and so
have looked into getting NYU to sign Microsoft's patent license
agreement.  In general, NYU has a pretty good history of supporting
open-source software--for example a lot of the early work on gcc2
happened here.  Thus, while different universities may react
differently to Microsoft's agreement, I would expect NYU to fall
towards the more accommodating end of the spectrum.

Because the agreement potentially gives Microsoft a license to NYU's
patents, it must be signed by our Office of Industrial Liaisons
(OIL)--what many universities call the "tech transfer office."  I
spoke with someone from the OIL today.  While we did not fully resolve
the issue, I did learn several interesting things.

First, while NYU has of course signed many different license
agreements in the past, there is no precedent for granting this kind
of blanket license to all applicable patents.  Thus, at the very
least, we're entering uncharted territory.

Second, the fact the license applies not just to Microsoft, but also
to all of Microsoft's licensees, is also unusual.

Third, the fact that paragraph 1.6 defines Necessary Claims as
applying to patents owned or controlled "at any future time"
significantly complicates matters.  It's one thing for NYU to take
stock of all current patents and applications and either decide they
don't apply or should be licensed to Microsoft and Microsoft's
licensees.  Committing to do so for future claims could, however,
affect researchers NYU hasn't even hired yet.

Given the unusual nature of the agreement and the unknown effect on
future hires, getting such a license executed would at the very least
require a "big push."  The agreement would also have to be vetted by
NYU's office of legal counsel.  My interpretation of our discussion is
the license terms created an uncomfortable and difficult situation,
and raised questions far broader than a single faculty member's
research.  Thus, because Sender ID has not been standardized yet, and
because I'm starting to think there are technically equivalent or
superior solutions that don't infringe on Microsoft's pending patents
(or at least on the subset of Microsoft's claims that they are
offering to license with this agreement), I did not deem it worth
pushing the matter further at this time.  (Also, because of the GPL
question and the extensible nature of Mail Avenger that easily allows
for non-compliant uses of the same technology, I'm not 100% sure I
could implement Sender ID anyway, so I didn't want to waste too many
people's time.)

If there are any other university faculty or staff members on the
list, would you be willing to inquire at your institutions to get a
sense of what it would take to execute Microsoft's Sender ID
agreement?  At this point, I'm guessing that, depending on the
university, the answer will lie somewhere between "major headache" and
impossible.

When evaluating the Sender ID proposal and licensing restrictions, I
would urge people to keep in mind just how much mail software has
originated from a university environment.  In particular, if you
simply counted the number of running MTAs in the world, I suspect
there are many more machines running sendmail--which originated from
Berkeley--than Microsoft exchange.  For that reason alone, I think it
would be bad to standardize on a technology that shuts out or vastly
complicates life for people releasing software at universities, unless
there is some truly compelling technical advantage to the proprietary
technology.

While I have seen several arguments for Sender ID on this list, none
has really made the case that it is a vastly superior technology.
Perhaps the best argument is that Microsoft will more likely adopt
Sender ID than an alternative technology.  While it would be great for
Microsoft to adopt whatever standard MARID produces, they will still
be free to do so even if the standard isn't covered by their patents.
Conversely, it may be much harder or impossible to produce
standards-compliant software at universities if doing so requires
executing Microsoft's agreement.  Also keep in mind that even for
sendmail, Sender ID will be an add-on package.  If it's not on by
default in all OS distributions, this will further reduce deployment.

Another argument for Sender ID is that it may be better for MUA
support.  Certainly Microsoft has a bigger share of the MUA market
than the MTA market.  There is also value in being able to show a
golden padlock or some similar icon by an email address in MUAs.
However, MUAs are not directly covered by the charter of the MARID
group.  (The "M", after all, stands for MTA...)  I also don't think
this is an issue if the MTA supports the standard--for instance
SPF-classic specifies a header that can contain information, like
mail-from address, that might otherwise not be available to the MUA.

Another argument for Sender ID is that sites won't implement SRS or
something equivalent required for SPF-classic.  However, first of all,
experience has shown that people are willing to implement SRS or
equivalent; a lot of forwarders have already stopped "forging"
mail-from addresses.  Second, independent of Sender ID, it's fairly
clear from list discussions that there is a serious need to block
mail-from forgery because of joe jobs, viruses, and possibly even
questions of legal liability.  Whether efforts to do so are officially
blessed by some future IETF standard, or else take the form of
SPF-classic becoming a de-facto standard, or worse take the form of
hard-coded ad-hoc rules for high-profile domains in people's spam
filters, the fact is that one way or another people who routinely
forge mail-from addresses are going to have reliability problems if
they don't already.

Yet another argument for Sender ID is that Microsoft's patents may
cover more than just core and PRA, or that somebody else's patents may
cover other technology.  However, the scope of Microsoft's license is
clearly restricted to core and PRA.  Thus, adopting Sender ID as a
standard does not help people if Microsoft's patent claims somehow
cover, say, the SPF record format.  It's also doubtful that
Microsoft's agreement would offer much protection against third party
patent claims.  After all, why would someone intent on enforcing a
patent claim covering the MARID standard even execute Microsoft's
agreement in the first place?

On top of that, it seems that the non-infringing SPF-classic offers
better protection against viruses and joe jobs, and has already
enjoyed small-scale but successful implementation and deployment.

Doing the cost-benefit analysis, it's hard to support adopting Sender
ID unless there is some compelling technical advantage to the
technology.  In discussions, I've seen vague references to banks and
third party mailers, but no concrete scenarios for which Sender ID is
really necessary.  For example, in this previous message:

http://www.imc.org/ietf-mxcomp/mail-archive/msg03912.html

I explore an example with a bank and third-party sender and find
roughly equivalent solutions with both SPF-classic and Sender ID.
Before standardizing the infringing technology, can people come up
with compelling scenarios that really require Sender ID?  Moreover,
can we convince ourselves that these scenarios couldn't also be
satisfied through small, non-infringing enhancements to one of the
other proposals?

David


<Prev in Thread] Current Thread [Next in Thread>
  • DEPLOY: Significant Sender ID license issues at universities, mazieres <=