Microsoft Releases Patent on SenderID

wayne writes "Microsoft has now put the SenderID patents under the OSP. The Open Specification Promise was discussed on slashdot before in conjunction with web services and it is good to see that they are opening up even more. There are still technical problems with SenderID compared with SPF and, of course, SPF isn't problem free. Still, over the last year, the number of SPF records has more than doubled from around 1.7 million to 4.1 million, with rate of growth increased in the last 6 months."

Have they released a SenderID SDK?

[Bucaro]

Although I may not be a fan of M$, I am a fan of anything anti-spam. How much coding does it take to make ones own email client, Mail, Thunderbird, or whatever, work with a senderID tag?

Sender ID, SPF, DomainKeys

[bcrowell]

So now we have Sender ID [wikipedia.org], SPF [wikipedia.org], and DomainKeys [wikipedia.org].

AFAICT, they all aim to accomplish similar things. Unfortunately, there's no consensus on which to use, and that means that they're all basically useless. One of these mechanisms would only become useful if virtually everybody used it, because then people could refuse to accept e-mail that didn't use it. Gmail and yahoo both use DomainKeys, which suggests that it's something that can really be implemented successfully in the real world. Looking at the Wikipedia articles, Sender ID seems to have problems because it breaks preexisting standards (see "Standardization issues"). My impression is that a lot of people looked at DomainKeys and said, "oooh, scary, it uses crypto." But hey, this is 2006, not 1992. Strong crypto is everywhere. Is there any reason not to go ahead and standardize on DomainKeys?

Why not just fix Windows?

[Anonymous Coward]

These days, the problem of spam is mostly caused by compromised Windows systems which unknowingly send out millions of such messages a day each. Thus the best way to fix the problem of spam is to get it at the root: Windows.

It won't be an easy task for Microsoft, but they'll need to bring the security level of Windows up to at least that of Linux, Solaris, MacOS X and the BSDs. Not only will they have to manage that for any new Windows products, but they'll also have to retrofit those security enhancements all the way back to at least Windows 95. They'll have to make sure that those changes don't break any existing applications, so it'll be a very significant challenge.

Re:Sender ID, SPF, DomainKeys

[RyanAXP]

SPF most certainly was not written by idiots, although MS's wacky SenderID carries the distinctive odor of cretinism. What you should perhaps understand is that SPF and DomainKeys/DKIM are complementary to each other, while SenderID bears all the hallmarks of yet another "just incompatible enough" Microsoft "extension" to SPF.

Re:Sender ID, SPF, DomainKeys

[DA-MAN]

For the record Google also checks the SPF, though I'm not sure if they actually do anything with it (as I've seen messages that fail still get through)

The following is from one of my emails:

Received-SPF: pass (gmail.com: domain of ***@yahoo.com designates 68.142.206.106 as permitted sender)

That's peculiar because Yahoo! doesn't publish SPF records.

Typical SPF Record:

$ host -t txt gmail.com
gmail.com text "v=spf1 redirect=_spf.google.com"
$

Yahoo!

$ host -t txt yahoo.com
$

Re:Why not just fix Windows?

[ATinyMouse]

I realize this is Slashdot and Microsoft is a convenient scapegoat, but I have to disagree with your statement. Compromised Windows systems may play a large roll in SPAM delivery today, but they aren't the root of the problem. If you want the root, look at any ISP that allows unauthorized hosts to send mail. They deserve far more blame then Microsoft does. You'd think with the cost of bandwidth, the tools available for detecting, and the problem with SPAM today, ISP's would be doing everything they could to tighten up their network. It doesn't really cost anything to put in blocks on port 25 and only allow traffic from authorized hosts, like their own email servers and customers paying for that capability.

nice, but lacking teeth

[oohshiny]

The terms of the OSP "promises" seem fine: irrevocability, general applicability, etc.

The trouble is that it's a "promise". A "promise" on a web page is not the same thing as a legally binding commitment.

The proper thing to handle this would be for Microsoft to submit the specification to a standards body with a legally binding contract and steep penalties should Microsoft break the contract and take legal action against anybody implementing the specification.

I can't tell why they aren't doing this. It could be

* arrogance ("we're too big to have to make a binding commitment to anybody"),

* it could be ignorance ("if we promise, it ought to be good enough"),

* or it could be nefarious ("the OSP will be good enough for commercial implementors, but it's not FOSS compliant", "they think it's open and binding, but we have hidden this pitfalls in the fine print").

Any guesses?

Note that Microsoft's spec is not needed, since there are already alternatives.

Re:Breaking SMTP not a solution

[fruey]

That's a fair point. I suggested the DJB link as a talking point, and I'm glad it brought out an intelligent response. I just said it was an "interesting take" and has some ideas which are worthy of discussion.

For major businesses RSS & such would be a good way to deliver "subscriber" content. Bloggers can do the same. They can also take advantage of proxy hierarchies. Bandwidth is getting cheaper anyway. Newsletters sent massively are exploiting the same weak link that SPAMmers exploit, so it's a tough call!

The line between SPAM and opt-in newsletters is something that makes the process difficult. Most Internet protocols are based on trust, store & forward, and good network configuration. Where you can catch SPAM is to axe everything in your policy to fight it around bad config.

That is what I retain as my key point: better DNS config, better SMTP/MTA config... if marketing people have to send better formatted newsletters and run well configured DNS servers... Hotmail / GMail / Yahoo can already fix some rules for that and begin to oblige the newsletter sender's SMTP/MTA/DNS chain to be better configured.

The original MS patent license & v=spf1 vs. PR

[Julian Mehnle]

Some of what you write is debatable, but some isn't.

The original patent license terms were not unusual or unreasonable. It was just that a number of persons decided to make an objection in this case to a practice that nobody had objected to for over a decade.

Saying that is ignoring the facts. Both the ASF [apache.org] and the Debian [debian.org] project classified the Microsoft's license for their patent as inherently incompatible with free software. And patents on e-mail standards, unlike patents on many other IT technologies, are a very particular problem because a very large (if not the larger) part of the e-mail server world runs on free software. Go read the ASF's and Debian's explanations, they certainly did do their homework.

Sender-ID is not incompatible with SPF as alleged. The only difference is at the recipient side and the recipient cannot be forced to interpret SPF or Sender-ID in any particular way.

(To be explicit about my motives: I am the one who appealed to the IESG/IAB on behalf of the SPF project about the reuse of "v=spf1" records for the PRA algorithm [wikipedia.org] in the Sender ID specification.)

You correctly point out that a communication standard is little more than a silent agreement between senders and receivers that only works if the receiving party tries their best not to misinterpret what the sending party meant. But then you simply quit the subject, assuming that communication standards will work even with everyone interpreting stuff their way, because, after all, there is no protocol police, thank you. Sorry, but "compatible" means something else to me.

We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

Again you are missing the facts. Quoting from my appeal to the IESG:

It is also worth noting that at the time the MARID WG was closed [in September 2004 [imc.org]], the then-current Sender ID specification draft-ietf-marid-protocol-03 [archive.org] did not include the re-use of "v=spf1" records for PRA checking. This was only introduced in [Microsoft's] individual submission draft-lyon-senderid-core-00 [archive.org] in October 2004. Also did Microsoft's record generation wizards generate only "v=spf2.0/pra" records [listbox.com] until the end of October [listbox.com], when they began generating only "v=spf1" records.

Read the appeal [ietf.org]. It connects a lot of dots that many do not like to remember.