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."

Comments

Why the hell did Microsoft have to go and...

[Avillia]

...Make a new grading scale for suntan lotion? I mean, honestly, we've already got Sun Protection Factor, we don't need some retarded system like SenderID... Hell, we don't even need SPF, idiotic parents just can't think of their children and get the thick blue paste that WORKS instead of this new THE PURPLE FADES IN crap.

Honestly.

Re:Can we get the FUD tag now?

[nmb3000]

More MS FUD about being open

What? Do you even know what FUD is? Fear Uncertainty and Doubt. It's usually meant to mean the kind of news Microsoft might release saying "OMG Linux is insecure!!!~" or SCO saying "WTF Linux newbs must pay money or we'll sue!!!". Microsoft trying to show some interest in open standards certainly does not qualify as FUD, especially since this isn't the first open stuff they've done.

• (no smoke without fire)
  
• Not to be the boy who cried wolf
  
• count the brass tacks
  

I think we have a finalist for the category 'Most Useless Cliches in a Slashdot Post'. Congratulations, however I've never heard of actually counting the brass tacks (though it appears I'm not alone) :)

Sender ID, SPF, DomainKeys

[bcrowell]

So now we have Sender ID, SPF, and DomainKeys.

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?

Re:Sender ID, SPF, DomainKeys

[Zeinfeld]

Actually Sender-ID and SPF are the exact same thing. Both allow the sender to describe their email sending configuration in identical terms. The only difference is what receivers decide to do with the information. That part is outside the scope of any sane spec since the whole point of spam control is that the recipients not the senders get to decide.

There is a big difference between Sender-ID and Domain Keys, Sender-ID uses the IP address of the outgoing email server. DKIM uses public key cryptography. We knew at the start that it would take about four years to agree a cryptographic standard hence the decision to adopt a two track approach.

This is not a VHS vs Betamax competition. There are genuine differences in the specs. If you are going to deploy one you have to do much of the work required for the other.

One of the core problems in MARID was that most of the people involved had little experience of the standards process and no inclination to accept reasonable compromises. Another problem is that the IETF rushed the formation of the group in order to prevent a rival standards body moving in on their turf. This pre-empted the negotiations I was moderating in an attempt to agree on a common proposal before the working group was chartered. As soon as the WG was chartered with an open charter the way was open for third party groups to introduce additional proposals even though they had no support from any constituency.

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. As a result of the SCO case the patent lawyers at several large companies (not just Microsoft) had determined that the reciprocation clause in the traditional open patent license was probably not enforceable if there was an open sublicense clause.

Some people decided to make SPF the place to fight this particular battle and started making unjustified accusations of bad faith on Microsoft's part. Then a splinter group decided to exploit the situation and propose a completely unrelated specification that had no commercial support whatsoever.

The point that was lost on many participants was that the only reason to go to a standards body is to get buy in for a proposal. If you want the best technical proposal you should not involve more than five people in the design.

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. We had agreement in the WG to proceed on a common spec and nobody found any problems until the patent issue was raised.

You disgust me

[suv4x4]

This is Slashdot, and there's not even ONE anti-Microsoft post modded up!

Re:Have they released a SenderID SDK?

[grcumb]

Although I may not be a fan of M$, I am a fan of anything anti-spam.

I'm not. Not a fan of anything at all, that is. I'm a fan of open systems (preferably officially endorsed standards) that are well understood and secured for use many years into the future. SMTP, for all its baggage, is one standard that has actually aged fairly well over the years.

There are fundamental flaws, of course, and now these flaws are costing us a lot of money, time and effort trying to stop people from preying on the system and on human naïveté.

Microsoft's approach to this can be summarised as, "Hey gang let's all get together and fight spam my way!" This is okay, but in the opinion of this hoary old curmudgeon, I'd rather people said, "Hey gang, let's all get together and figure out how to fight spam!" There's a small but integral difference between those two statements. It lies in the potential for Microsoft to stop in mid-fight, take its ball and go home.

What Microsoft is trying to do with this latest move is to convince the world that it will not do this. I'd like to believe that's true, but their track record gives us every reason to believe the opposite. Even if they're perfectly sincere about this right now, people will still be suspicious that at some time in the future they might try to lock things down again.

It's unfortunate that we have been led to feel this way, and I suppose it's never to late for a leopard to change his spots. I doubt this one will, though.

Re:Have they released a SenderID SDK?

[Keeper]

Email clients are not what SenderID is for: it's for mail servers, to reject the spam before it even gets into the user's cue.

SenderID can be implemented on both mail servers and clients.

Unfortunately SenderID is not only patented, the Microsoft license prevents other people from modifying it for other uses. This means it should not and cannot be used in Sendmail, Postfix, or other open source MTA's due to license restrictions.

Wrong: http://www.microsoft.com/interop/osp/default.mspx

SenderID is also cryptographic. This prevents software with it integrated from being exported to "restricted" companies, due to the strange rules about encryption being a material of war.

SenderID has no cryptography. You're thinking DomainKeys.

SenderID is also fundamentally broken: SPF rejects spam messages in a way that is very lightweight and free to implement (publish a TXT record in your domain's DNS), and rejects the message before its contents are even sent, based on the "FROM" line used for email bounces.

Incorrect. Both SenderID and SPF are based off of DNS TXT records. The primary difference between the two is that SenderID validates that the FROM field has not been forged, while SPF validates that the return path has not been forged.

SenderID requires purchased keys from Microsoft, and requires the MTA to accept the email message to process the SenderID key, which seriously burdens the server.

SenderID basically has nothing to do with SPF or anti-spam: it has to do with selling keys for bulk emailers, legitimate or not, to send bulk email while avoiding anti-spam messages. Its presence in a message is actually a very powerful sign that the message is spam, just as those "Haiku" messages in email headers used to be.


SenderID has no cryptography. You purchase nothing from Microsoft. You're thinking DomainKeys.

Unfortunately, the creators of SPF accepted Microsoft sponsorship and involvement with SenderID to get Microsoft support, integrating SPF-like features into Hotmail and other Microsoft tools in order to get a larger user base, but unfortunately accepting a corrupt influence that has actively hindered the acceptance of SPF.

Blah blah blah, insert Microsoft is teh big evil rant here. You should learn what you're talking about before complaining about something it doesn't do.