The IETF MARID working group has been slogging away all summer trying to produce a draft standard about e-mail sender verification. They started with Meng Wong’s SPF and Microsoft’s Caller ID for E-mail, which got stirred together into a hybrid called Sender ID.

One of the issues hanging over the MARID process has been Microsoft’s Intellectual Property Rights (IPR) in Caller ID and Sender ID. The IETF has a process described in RFC 3668 that requires contributors to disclose IPR claims related to their contributions. Microsoft has sent in some oracular IPR disclosures about patent applications relative to Caller ID and Sender ID, but with little detail since the applications hadn’t been published. But last week, they were published.

I have read the two Microsoft patent applications published last week and analyzed the claims. I’m not a patent lawyer or patent agent, but I have read enough patents over the years that I think I can do an adequate job of figuring out what their claims cover.

Visit the USPTO application search page and search for 60/454517, the serial number of the provisional application from which they both derive, or you can download PDF versions from my web site for application number 20040181571 and 20040181585.

Patents consist of a narrative description of the invention, followed by claims. A claim can be independent, standing on its own, or dependent, based on a previous claim. Dependent claims are generally minor tweaks to independent claims, so I’ll look at each independent claim and all of its dependent claims as a group.

Application 20040181571

This application is the less troublesome of the two. About 2/3 of it deals with methods of detecting IP spoofing, which aren’t relevant here (or, if you ask me, anywhere else since TCP stacks started randomizing sequence numbers.) The rest describes what is essentially Caller ID.

Claims 1-8 and 10-21 cover anti-IP-spoofing techniques. (There’s no claim 9. Oops.)

Claims 22-38 cover Caller ID. Claim 22 says:

22. In a receiving domain that is network connectable to one or more sending domains, the receiving domain including one or more receiving messaging servers configured to receive electronic messages from sending domains, a method for determining if a sending messaging server is authorized to send electronic messages for a sending domain, the method comprising: an act of receiving an electronic message purportedly sent from the sending domain;

an act of examining a plurality of parameter values of the electronic message to attempt to identify an actual sending side network address corresponding to a sending computer system;

an act of querying a name server for a list of network addresses authorized to send electronic messages for the sending domain;

an act of determining if the actual sending side network address is authorized to send electronic messages for the sending domain;

and an act of providing results of the determination to an message classification module such that the message classification module can make a more reliable decision as to classifying the received electronic message.

Note the word “plurality” in clause 3, which is patent-speak for “more than one”. I believe that SPF classic, which only checks a single message parameter, the bounce address, isn’t covered here. SPF may also check the HELO domain, but that’s not a parameter of the message, it’s a parameter of the connection. Yes, this is hair-splitting. Welcome to the wonderful world of patents.

Claims 39-41 and 42-45 cover anti-IP-spoofing.

Claims 46-49 cover Caller ID again, phrased in a different way. They also refer to a “plurality of parameter values of the electronic message”.

Application 20040181585

The claims in this application are breathtakingly broad. Along with a lot of computational puzzles, which we don’t care about, they cover a wide class of sender verifications and, as an afterthought, scoring spam filters.

Claims 1-18 cover sender verification. Claim 1 is extremely broad:

1. In a receiving domain that is network connectable to one or more sending domains, the receiving domain including one or more receiving messaging servers configured to receive electronic messages from sending domains, a method for determining a sending domain’s electronic message transmission policies, the method comprising: an act of receiving an electronic message from the sending domain;

an act of receiving one or more electronic message transmission policies corresponding to the sending domain;

an act of parsing relevant electronic message transmission policies from the one or more received electronic message transmission policies;

and an act of providing the relevant electronic message transmission policies to a message classification module such that the message classification module can make a more reliable decision when classifying the received electronic message.

To me, that covers SPF, Caller ID, Sender ID, and any plausible variation on them that calls back to the message domain for advice on handling the message. By some readings it might also cover CSV, but from the narrative text it’s clear that they’re talking about message domains, not host domains. Paul Vixie’s original domain verification proposal was published in May 2002 and he said it wasn’t new at that time, so I have my doubts about the novelty of this claim.

Claims 19-20 roughly restate claim 1.

Claims 21-35 and 36-44 cover puzzles.

Claim 45 is similar to claim 1.

Claims 46 and 47 are about puzzles.

Claims 48-49 come out of left field and cover scoring spam filters:

48. A computer program product for use in a receiving domain that is network connectable to one or more sending domains, the receiving domain including one or more receiving messaging servers configured to receive electronic messages from the sending domains, the computer program product for implementing a method for generating inputs to be provided to a message classification module, the computer program product comprising one or more computer-readable media having stored thereon computer executable instructions that, when executed by a processor, cause the receiving domain to perform the following:

receive an electronic message;

utilize one or more of a plurality of different mechanisms for attempting to determine if the received electronic message is an unwanted or an unsolicited electronic message;

and provide results of each of the one or more different mechanisms to a message classification module such that the message classification module can make a more reliable decision when classifying the received electronic message.

Since Spamassassin 1.0 was published in Sept 2001 and did exactly this, classify messages based on several criteria, I find it hard to understand how they’d claim this as new in a 2003 patent application. Surely they are familiar with Spamassassin.

Summary

Keep in mind that these are just applications, and we don’t know whether the USPTO will issue a patent and if so which if any of the claims would be allowed. I assume that their other applications are similar, and we don’t know what if anything will issue in other countries.

The issue that concerns me most is that the claims in these applications, particularly in ‘585, are much broader than what Microsoft’s IPR disclosed. Note that since the IPR documents are written by lawyers, not techs, I’m not faulting any of the Microsoft employees who have been participating in MARID and don’t get to set their employer’s policies.

If ‘585 issues as a patent in anything like its current form and Microsoft’s license doesn’t change, it would make SPF or any other similiar system legally very risky since the MS license only lets you implement Sender-ID, not other things that are like Sender-ID. Regardless of what the MS IPR said, their patent rights depend on what’s in the patent, and if you look at cases where patents were broader than the IPR disclosure in the standards process, the results can be really ugly. Google for RAMBUS JEDEC for a notorious example.

At this point, I see a variety of unappetizing alternatives. One is to wait and see what patents issue, but that could take years. Another is to standardize only what MS is willing to license. Or we could decide that the ‘585 claims are implausible and ignore them, at our peril.

My personal inclination is to say that none of the domain/IP verification schemes are good enough to be worth this much heartburn, put them all back on the shelf, deal with the less controversial CSV and BATV proposals, and turn our attention to message signatures in the new MASS working group.