Microsoft Releases Patent on SenderID 128
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."
Re:Can we get the FUD tag now? (Score:5, Informative)
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 [sourceforge.net].
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 [google.com])
Re:Sender ID, SPF, DomainKeys (Score:5, Informative)
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.
SPF/Sender-ID is great in theory (Score:3, Informative)
Counterexample that proves the point! (Score:1, Informative)
$ dig paypal.com txt
paypal.com. 472 IN TXT "spf2.0/pra mx include:s._sid.ebay.com include:m._sid.ebay.com include:p._sid.ebay.com include:c._sid.ebay.com include:spf-2._sid.paypal.com ~all"
paypal.com. 472 IN TXT "v=spf1 mx include:s._spf.ebay.com include:m._spf.ebay.com include:p._spf.ebay.com include:c._spf.ebay.com include:spf-1.paypal.com ~all"
If your mailserver checks for SPF, it will notice that paypalscam.ru is not on the list of paypal.com approved senders and make a decision. Whether you configure your mailserver to check spf--and what you do with that information--is, of course, up to you. You can tell it to reject the message outright, or to put in a notification header and alert the user.
Don't blame SPF if you choose to disregard what it tells you.
When to use SPF instead of DomainKeys (Score:3, Informative)
SPF lets a domain administrator specify that all mail from that domain will come from one of the specific servers, so you can trash crude forgeries quickly at the cost of a couple of DNS lookups, and incidentally trash a lot of phishing spam without burning up lots of CPU.
DKIM lets an administrator specify crypto keys that will be used to sign real email from that domain, so you can validate it at the cost of a lot of CPU. That's useful for checking mail that purports to be from *your* bank but might be a *good* forgery. But it's a waste of CPU for checking mail from banks you don't care about, or the 99.44% of purported PayPal/eBay messages that are fake, since you can use SPF to discard the ones sent by zombies, Chinese spammers, address-space hijackers, etc.
So maybe you want both, or maybe you'll use other methods to deal with the good forgeries. But SPF lets you trash a lot of the crude phishing spam before you do any heavy lifting. (Of course, it won't protect you from mail purporting to be from PayPalSecurityLtd.co.uk or Paypal.aq, and spammers will fight back by polluting the namespace, but it's at least some help.)
Re:Sender ID, SPF, DomainKeys (Score:1, Informative)
As long as 1) the sender uses the h= tag to list the headers it has signed*, and/or 2) the in-between server inserts its headers at the top of the message as specified in RFC822, the signature will still verify no matter what headers are added between sender and receipient.
The only way to break the signature is to modify the original headers or body, or inserting new headers below the DomainKey signature.
Please read the spec before describing weaknesses in the protocol.
* If the h= tag is used, these in-between servers can modify headers that aren't listed in the h= tag without mooting the signature.
Mod Parent Up, Please (Score:3, Informative)
On the other hand, I've never had a problem with forged mail from the Bank of Nigeria, so maybe they don't need to use it
Re:Sender ID, SPF, DomainKeys (Score:4, Informative)
But it's a huge difference for the receiver, whether or not you feel it's sane.
1) SPF regulates the envelope sender. Sender-ID regulates the TO: field.
2) SPF can be used to reject incoming messages before any data is sent. Sender-ID has to (at least) wait for the TO: field to be sent along with the rest of the DATA part -- which doesn't limit bandwidth consumption very much.
3) If the MTA isn't going to reject messages and only add to the score, then Sender-ID will be fine for you. If you want to reject messages to avoid tying up your MTA (and lower your bandwidth consumption), SPF is the way to go.
And for the parting shot (not against the parent), DomainKeys is just too much of a load on a busy server, IMHO, because it requires computing a hash for every single message. It just doesn't scale. It has other severe problems too, but I saw them adequately discussed earlier.
Re:Have they released a SenderID SDK? (Score:2, Informative)
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 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. 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.
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.
Make no mistake, SPF has problems. It breaks most email forwarding unless the forwarder uses SRS or some other tool to rewrite the email address to send bounce messages to. But it's very lightweight and effective, and the email forwarding was already badly broken and needs fixing.
Re:Have they released a SenderID SDK? (Score:4, Informative)
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 [microsoft.com]
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.
Re:Have they released a SenderID SDK? (Score:1, Informative)
Here's my shocking intro: I'm not for just "anything" anti-spam.
I've said all this before on
The Sender Policy Framework (SPF) so-called spam solution is being adopted all over the place without nary a complaint. But think about it. Tim Berners-Lee didn't just envision a web of equitable bandwidth, he envisioned a web of peers---a web of end points, all equally valid. What happens when my system is no longer considered a valid end point? Suddenly, we have a network of clients and servers rather than peers. When the SPF process looks to verify that the sender is the one valid smtp server for the mail address' domain (based on either MX or A records), it devalues all non-domain level systems on the web. Peers on the network become clients, fed valid packets from those servers that are approved to pass said packets. The SMTP semantic paradigm moves from Sender>Receiver to Server>Client.
But no one really cares because there is some belief that this will help reduce spam. It will, but so will turning off our mail clients. Neither is the right solution. The solution is a newer, better mail protocol, many of which have been proposed that DO NOT devalue the peers of the network. Probably one of the better known of the examples is the IM2000 protocol [homepages.tesco.net].
But we'd rather have a network of tiered rights, I suppose, than deal with the mess of changing a protocol for real.
In programming cicrles, this is called cruft. "What, the exosting app doesn't do all that's needed becuase we didn't think we'd need this functionality? Then just tack that functionality on it." Sometimes it makes sense to add small functional differences to an extant app. Sometimes it makes more sense to just move to an app that does what you want out of the box instead. This is an example of the second, but as a community, the Internet seems to have decided to do the first. the ISP's love it. It further adds control in their own hands (server-client models make them more powerful online) but why in God's name should we agree to use it?
Tom Caudron
http://tom.digitalelite.com/ [digitalelite.com]
Re:Sender ID, SPF, DomainKeys (Score:3, Informative)
The default is to guess at permitted relays for a domain, so smtp.example.com would be allowed to forward @example.com email. Perhaps it should have read:
but that's a bit more verbose.
Keeping separate issues separate (Score:2, Informative)
Given the mostly-free-software nature of the e-mail server world, I consider that a feature. But of course I'd prefer the IETF to adopt an institution wide free-software-compatible IPR policy.
I doubt that's true. I think the ASF (and Debian) position was that there was no alternative but to have a free-software-compatible patent license. Nobody really cared why this requirement postulated by some wasn't met (i.e. whether it was due to Microsoft's marketing strategy or whatever), just that it wasn't met. There would have been no point in ceding that position because, assuming MARID would have successfully produced a protocol, then it couldn't have been implemented by all the free MTAs and other free e-mail software out there. It seems that even Microsoft has now come to recognizing this fact.
There are two issues that you need to keep separate. A: people objected to the inclusion of a technology in the upcoming e-mail authentication standard that was covered by a free-software-incompatible patent license. B: people objected to their "v=spf1" records being deliberately misinterpreted, causing technical problems for them. IMO, both objections were (and are) justified, but still these are separate issues.
Now that a technology covered by a free-software-incompatible patent license (=PRA) has not become part of the upcoming e-mail authentication standard (now there is not "one"), nobody really cares much anymore what happens to the PRA license. Only the technical issues of the "v=spf1"/PRA reuse (B) remain.
Because "royalty free" isn't the same as "free software compatible". The former as in "free beer", the latter as in "free speech", yadda yadda [wikipedia.org]. As a developer of free e-mail software, I did not wish to be excluded from implementing the upcoming e-mail authentication standard, so I shared the objection.