Slashdot Log In
Microsoft Releases Patent on SenderID
Posted by
ScuttleMonkey
on Mon Oct 23, 2006 10:26 PM
from the sharing-your-toys-in-the-sandbox dept.
from the sharing-your-toys-in-the-sandbox dept.
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."
Related Stories
[+]
Microsoft Won't Assert Web Services Patents 155 comments
Andy Updegrove writes, "Microsoft has just posted the text of a new promise not to assert its patents with respect to 35 listed Web Services standards. The promise is similar to the covenant not to assert patents that it issued last year with respect to its Office 2003 XML Reference Schema, with two important improvements intended to make it more clearly compatible with open source licensing. Those changes are to add an explicit promise not to assert any relevant patents against anyone in the distribution chain of a product, from the original vendor through to the end user; and to clarify that the promise covers a partial as well as a full implementation of a standard. It's all part of a recent wave of such pledges made by companies such as IBM, Nokia, and Oracle, and a significant shift in how Microsoft is dealing with open standards."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Why the hell did Microsoft have to go and... (Score:5, Funny)
Honestly.
Re: (Score:2)
Re:Why the hell did Microsoft have to go and... (Score:4, Funny)
Parent
Have they released a SenderID SDK? (Score:3, Interesting)
Re:Have they released a SenderID SDK? (Score:5, Insightful)
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.
Parent
Re: (Score:2, Informative)
SenderID is also cryptographic. This prevents software with it integrated from being exported to "restricted" companies, due to the strange r
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.
Parent
Re: (Score:3, Insightful)
The Internet didn't start with the Web, after all.
Brr... (Score:2, Funny)
Re: (Score:2, Funny)
from http://weather.yahoo.com/forecast/USMI0672.html [yahoo.com] , the weather on 23 October 2006 at 12:15 am EDT is:
Fair, 34F.Barometer is 29.93 in and steady, and 87% humidity. There is a 7 mph west wind.
Of course, conditions will change, so keep on watching for Hell to freeze over.
Sender ID, SPF, DomainKeys (Score:5, Interesting)
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?
Re: (Score:2, Insightful)
In short, DomainKeys wasn't designed by idiots, while the other two apparently were.
I'm unbiased! pffffft
--
phil
Re: (Score:2, Interesting)
Re:Sender ID, SPF, DomainKeys (Score:4, Insightful)
DomainKeys breaks a lot of things. As one of the maintainers of the QmailToaster [qmailtoaster.com] project, I've run across a lot of people where DomainKeys breaks their entire setup.
1) If you forward your mail to an upstream server (sendmail smarthost, Exchange SMTP Connector, etc), DomainKeys will always be void.
2) If you have a backup mail server or a scanning mail server that receives and then transfers to your primary mail server un-modified (IE doesn't remove the DomainKeys) then your main mail server will reject it.
DomainKeys sucks. SPF sucks, SRS is a hack.
Parent
Re: (Score:2)
I will speak to DKIM since that is what the IETF [ietf.org] is standardizing on, and that is the code you can get for free on SourceForge. DKIM's biggest advantage is that it does not care about how the mail
Re: (Score:2)
huh? Your upstream rewrites all your headers or changes the body content? Since when is it ok for an upstream to do that?
From http://antispam.yahoo.com/domainkeys [yahoo.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.
Parent
Re: (Score:2)
MS wants people to think they are pro standards but look at their implementation record. Not pretty.
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.
Parent
Re: (Score:2)
The original MS patent license & v=spf1 vs. PR (Score:2, Interesting)
Some of what you write is debatable, but some isn't.
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
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
Re:Sender ID, SPF, DomainKeys (Score:4, Interesting)
The following is from one of my emails:
That's peculiar because Yahoo! doesn't publish SPF records.
Typical SPF Record:
Yahoo!
Parent
Re: (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.
You disgust me (Score:5, Funny)
MS could start the adoption wave (Score:2)
Maybe something like how the "nofollow" tag became a standard to stop comment-spam on blogs. It isn't any official standard, but when blogger, and mov-type, wordpress and google followed it became an unofficial standard.
Re: (Score:2)
Far more effective is askismet or other blog comment controls. If you set up a site and then invite comments, then you should moderate your own comments, it is that simple.
SPF/Sender-ID is great in theory (Score:3, Informative)
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
nice, but lacking teeth (Score:3, Interesting)
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: (Score:2)
We've seen very similar issues with SSL keys and the restrictions on the root signature authorities: Microsoft wants to remain the
Microsoft Office XML specs (Score:2)
Breaking SMTP not a solution (Score:3, Insightful)
All of these solutions have flaws. I'm with deBoynePollard on this:
An interesting take is to make the sender responsible for storing mail [cr.yp.to]: suggested by Dan Bernstein (DJB), the qmail guy.
There's always politics in it. Some people don't like DJB's attitude and they're anti-qmail and go for Postfix or sendmail.
Wietse Venema, the postfix guy, isn't too happy about SPF either [irbs.net]: but he does provide plugins for Postfix.
SPAM needs a solution, but breaking SMTP isn't the way to go IMHO. I think a well configured email server, RBLs, requiring reasonable RFC compliance and such will eliminate much SPAM. Spending energy on evangelising good mail server configuration is still the best way to go.
Re:Breaking SMTP not a solution (Score:4, Insightful)
As per typical DJB ideas, it's broken and only implements half the functionality of what it intends to replace. I've used this example before, so skip this if it sounds familiar:
A friend of mine hosts a customer that sends weekly newsletters to about 25,000 subscribers. With SMTP, my friend can spool the whole set and then watch as the mail queue flushes over time (measured in a small number of hours). It takes advantage of the fact that if 10,000 of those newsletters are going to @example.com addresses, it can deliver all 10,000 of them at once. In any case, his system delivers mail at the pace it can handle.
Enter DJB's scheme. Now, my friend delivers 25,000 "you've got mail!" notifications. Then, he watches in horror as 9AM EDT rolls around and 5,000 of his customer's customers simultaneously try to fetch unique copies of the newsletter to read with their morning coffee. Repeat at 9AM CDT, MDT, and PDT. His choice is to get out of the newsletter delivery business, or spend $$$$ on vastly increasing his bandwidth.
Basically, it's fundamentally broken. SMTP is more or less optimized for throughput. DJB's plan is more or less pessimized for latency.
Parent
Re: (Score:2, Interesting)
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 toug
Re: (Score:3, Insightful)
Of course, you say this as if his newsletter doesn't contain any hyperlinks to http://yourfriendswe [yourfriendswebsite.com]
Of course (Score:2)
And have you heard about the "extra secure" features of exchange 2007? It would restrict you to geting mail only from other exchnage 2007 servers... For your security of course. Its for the kids too.
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])
Parent
Re: (Score:2)
If course he knows what FUD is. But why stop there.
This FUD about MS being open is nothing compared to the FUD that Vista is secure or the FUD that IE7 is a decent browser.
The worst FUD is that Microsoft isn't some evil empire of giggling mutants who want to take over the world: it's in fact lots of smart (and some not so) developers working on their designated products, some marketing guys, some clerks and some lawye
Re:Huh? (Score:4, Insightful)
Parent
Re: (Score:2, Interesting)
Re: (Score:2)
Mmmm, SPAM rolls, home delivered? Delicious and convenient. Why would anyone object to that? ... Oh, you must have meant "spam."
Re: (Score:2)
If someone started filtering ports or doing whatever kind of crap upstream of me, I certainly wouldn't be amused. This could be somehow mitigated if the filters could be lifted
Re: (Score:2)
You obviously haven't experienced the problem of running a large mail server and having 50,000 fake email worm messages with your client's "FROM " addresses or other forged data cause the bounces to hammer your mail server into uselessness. The fakery of the "FROM " line is different than the classic "From:" forgery: it causes the faked serv
Re: (Score:2)
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.
You mis-spelled 'Users' there, chief.
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.
Given that all currently supported versions of Windows, from a technical perspective, have
Re: (Score:2)
Re: (Score:3, Insightful)
It doesn't matter if these security measures are there if noone uses them. Windows still ships with new user accounts being administrator by default. The default group policy is very permissive, and acls do nothing versus the administrator user. If windows had decent sudo capabilities (yes I have used
Re: (Score:2)
So far although the system has gotten a bit more useable (or rather less brittle), killing the thing and starting over hasn't yielded stellar results either (except to the bottom line, which is the only one that really counts of course). Plus it still needs fixes
Re: (Score:2)
I was having this problem, so I added SPF records for my domains. Then spammers started using another one of my domains and the spam started going up, not down.
Re: (Score:2)
That's a false hope. I know from very direct experience that it does not work today, and logically it is unlikely to ever work.
The underlying reason that "blowback" from forged spam is a problem is that a lot of people are still running mail systems that are designed (to whatever degree they are designed rather than thrown together) with mid-90's