Slashdot Mirror
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."
...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.
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?
It's a little cold in hell for this time of year, don't you think?
> Okay, yes, that sounds vaguely troll-like, but lets be realistic
m l
I disagree sir, that sounds like a troll to me. There is nothing FUD about this story.
> Not to be the boy who cried wolf, but why does anything that MS does that even sounds vaguely like Open Source make the news if it isn't Open Sourced?
http://slashdot.org/articles/05/01/30/1433226.sht
Nature journal lied in Britannica vs Wikipedia Ask to retrac
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.
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)
"What do you despise? By this are you truly known." --Princess Irulan, Manual of Muad'Dib
/)
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?
Find free books.
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.
I am serious. No Troll. I am just sick of the damn cialias, viagra, whatever the hell they come up with next emails and having to change my email address all the damn time. I figure if M$ does come out with SenderID, even if they are using FUD, I can actually open my inbox without deleting half of it. I have email addresses that I have never used for anything outside of school that get spammed with stock quotes or random crap all the time. With M$ putting some money behind SenderID and getting a few people to join up with them (even if they are only screwed later -- think Zune and Plays for sure) then there will still be a large following. Maybe making SenderID standard with outlook express with vista they can get the standards ball rolling. I can even see the warning now .... the message you are about to read does not have a SenderID, and may possibly be spam. Have them download the latest version of Microsoft Outlook/Euntourage/Linux-STFU so the origin of this message can be verified.
Why do people compare MS to the Open Source community? Can't be done. Simple fact is, MS is a business, the Open Source community is eactly that, a community. The only reason businesses exist, is to make money.
Technophile
GP's grammar was correct. Admittedly it probably should have been "'Brass tacks' is an object," but he is referring to the words themselves, not the tacks. As there is only one subject to that sentence, the verb is correctly singular.
Office probably has crazy R&D and coding costs(even if you find the quality of Office to be lacking, it doesn't change that, outsourcing aside, the programmers coding it for MS don't work for peanuts...they probably make 2-3 times what I make, and I don't work for peanuts myself!), so recoding the whole damn thing (even if you port the Mac version, I'm sure it uses a lot of Mac-only API), plus support, etc, it most likely would come down to a loss, or a very tiny profit margin: not worth the customers they'd -lose- from people who would move from Windows to *nix when they see Microsoft's alternate products available there.
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 lawyers united under a common title.
This promotes doubt and uncertainty.
But it mostly promotes fear: be afraid, be really afraid!
This is Slashdot, and there's not even ONE anti-Microsoft post modded up!
One good thing about MS driving this is that unlike some standards body which can only prescribe what to do, they could start implementing this on Exchange servers. While most of the mail servers are _not_ Exchange, this could start the adoption cycle.
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.
Life is just a conviction.
However, until people start saying "these are the only mailservers permitted to send mail for my domain, anything else should be rejected outright", mailservers wont reject mail from support@paypal.com sent from paypalscam.ru.
You mention paypal. Paypal does, in fact, publish spf records:
;; ANSWER SECTION:
:)
$ 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.
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.
Not that I think OSP can be trusted, but it is interesting that the Microsoft Office XML specs apparently haven't even been released under OSP.
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.)
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
All of these solutions have flaws. I'm with deBoynePollard on this:
An interesting take is to make the sender responsible for storing mail: 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: 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.
Conversion Rate Optimisation French / English consultant
Embrace, extend, patent, restrict... we all know the routine.
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.
---- Booth was a patriot ----
How do you do that?
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.
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 assumptions that are no longer true:
The result is mail systems that accept mail rather promiscuously, storing and queueing it up for steps like filtering or forwarding to other internal systems for delivery. Those later steps can result in failure, and the mid-90's assumptions about mail lead to the decision to follow the traditional ruiles and generate a bounce for any failed message. SPF (or any other sender authentication scheme) can only help if those systems that are living in the past implement its use in deciding whether to accept mail and/or whether to generate a bounce for mail. Many blowback-generating mail systems can eliminate blowback completely (or for less cost: 5-nines complete) simply by rearchitecting for modern realities, without bringing SPF into the picture.
Being in the position of running largish mail systems, I can see quite starkly that SPF alone as a blowback control would do more harm than it is worth. Real mail systems get legitimate mail from domains run by fools who can't get their SPF records right and use "-all" as a trailing default. Real mail systems get mail transparently forwarded to them through sites that do not modify the SMTP sender, no matter how much the SPF cheerleaders would like them to. Real mail systems can't absolutely trust SPF when it is derogatory unless they are willing to accept occasional loss of otherwise perfectly legitimate mail.
Some of what you write is debatable, but some isn't.
Saying that is ignoring the facts. Both the ASF and the Debian 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.
(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 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.
Again you are missing the facts. Quoting from my appeal to the IESG:
Read the appeal. It connects a lot of dots that many do not like to remember.
Done.
Spammers don't seem to care; they still forge from my domains.
Mail servers don't care. They still send back bounce messages to me.
Now if my mail server could do the SPF lookup on the received lines in the bounced message and drop it, that would work. Without that, SPF doesn't help me without cooperation from everyone else.
Add TLS to the SMTP protocol. Force the sending server to encrypt with a certificate. This will not only eliminate 60% of all spam but most viruses. And it would solve the clear text issue. And it is a commonly accepted method. Sure it would add overhead, but would be well worth the cost.
What you do not seem to be aware is that the ASF lawyer who raised the issue had previously conceeded the exact same patent terms in the World Wide Web Consortium.
What he was really up to was attempting to use the IETF and the MARID WG in particular as an opportunity to reopen a position he had already conceeded. Furthermore I think you fail to appreciate the extent to which he is personally invested in the whole issue and in particular to his own approach.
The problem with the ASF approach that they never accepted is that they were bearing absolutely none of the risk if the theory of enforceable sub-licensing turned out to fail.
The problem with doing this in the IETF is that the IETF does not have an institution wide patent policy. Every WG creates its own policy. That in turn means that if Microsoft was to conceed the principle in this specific case they could not expect other companies to conceed the principle in future cases. The prcedent would have been set that Microsoft waives those rights but this precedent would not apply to any other party.
A large part of the fault lies in the IETF IPR policy which is uninteligible. It should not be open for individual working groups to negotiate these issues. The individual WG can only ask Microsoft to make a concession, it cannot offer a precedent that Microsoft can rely on in future.
If you fail to understand what people really want from a political negotiation you will fail to persuade them. The ASF position was that there was no alternative but for Microsoft to change. The idea that ASF might change was refused out of hand. The problem might have been solved by the rule book proposal I raised but this was dismissed out of hand.
The idea that a license was unnecessary and that what was really needed was a cure clause did not occur to me until much later. As you know I am not a lawyer, this is not my specialty. I have no idea if the Microsoft lawyers acted on my proposal or came to the idea independently.
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.
You keep returning to this hobbyhorse and you are still wrong.
In your model the sender of a message gets to decide how the information they provide will be used. Its absolutely the wrong model.
The obsession with blocking the PRA check only began when a few zealots started to worry about the fact that people might dare to check their email with Microsoft's patented PRA check.
Your emails to me go through multiple spam filters using patented techniques. The PRA has always been offered on royalty free terms. Why is that particular filter the one you make such a song and dance over rather than the royalty bearing ones?
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
I'm not. Not a fan of anything at all, that is. I'm a fan of open systems
So, you are. You are a fan of something afterall. You're a fan of hypocrisy.
No. This is a false dilemma. It's also the reason to use SPF right now, today, because SPF explicitly works around the problem of uneven adoption. You get a subset of the benefits of SPF just by implementing the easy half (publishing SPF in your DNS, a five minute job) and a larger subset by implementing the hard part (SPF checking, requires more knowledge). You get 100% of the benefits when the whole world uses it, true, but you get a huge benefit right off the bat - enough to be worth doing now.
I don't agree that because huge companies with titanic resources can use something that implies that everybody can use it. Put another way, professional basketball players can slam-dunk, that doesn't imply that anyone else can.
Well, there's the fact that DKIM is the successor to Domain Keys, so you might want to go with the more evolved standard instead of version 1.0. If you want an old standard that works, use SPF. Graduate to DKIM when it is supported by the vast majority of MTAs... like SPFv1 already is.
Oh, and getting back on topic: ignore SenderID. It's not only broken (the technical standard is factually incorrect) it's also just another big corporate "embrace and extend" strategy - dominate the market by forcing everyone else to spend resources on compatibility with your not-quite-to-spec implementation of a not-quite-standard. Ride SPF until you can switch horses to DKIM.
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. 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.
Gimme your home email address - I'll send 10,000 messages or so with you as the (forged) sender (return-address). Are you sure you want me to be considered an equal when it comes to sending mail from your email address?
So the solution is to extend SMTP with out-of-band identity of some sort. SPF is a protocol that says that I am not a valid sender for mail from your domain. This is a good thing. I'm only going to reject mail from "non-you" if you publish an SPF record that defines which mail servers you want identified as valid senders for you. If you don't publish an SPF record, I'm not going to make any decisions based on which mail server is connecting as you.
I did read some of the stuff you linked to re IM2000. What I read suggests to replace a push system with a push then pull system. I don't see that it would stop spam, nor would it stop forgery used to facilitate spam. At some point, to prevent forgery you need to look up a published identity. For SMTP, that would be SPF or SenderID. For IM2000, that would be... the equivalent of SPF or SenderID....
Did we really need a whole new email system for just that?
Worse, IM2000 breaks my single-instance-storage system unless the plan is to get ridiculously complex.
Sorry - I like SPF as a lightweight simple (opt-in) extension of SMTP. If you want to send email from any machine anywhere, don't publish an SPF record - I'll still accept email from you. Well, I'll trust it is you, although you might turn out to be Alan Ralsky. ;-)
"The most sensible request of government we make is not, "Do something!" But "Quit it!"
Unfortunately, it's completely unsubstantiated by facts or precedent.
(Note that while Microsoft called this a "promise", it's not the same as when, say, someone "promises" something as part of a business transaction. So case law about "promises" doesn't apply.)
I use -all and I stuck it in there on purpose. SPF's page says: -all No other servers are allowed to send mail from xxxxxx.com. This is a good default for sites particularly concerned about forgery.
What in your opinion is wrong with using -all? Is see a bunch of domains using ~all which I view as fudging on their part.
In the interim, you need SRS. That's right. SRS is problematic when used to work around forwarding problems (for receivers that don't know their own forwarders). But it works wonders in a signing mode. Have SRS rewrite the envelope of all your outgoing mail (I omit the SRS domain when it's the same as the outgoing domain). Discard (reject) bounces (empty MAIL FROM) that lack a proper signature. It cans a *ton* of crap - both forged bounces and bounces of forgeries.
Now if people would only stop sending DSNs without an empty MAIL FROM. I've found it useful to treat mail from certain localparts, like postmaster and mailer-daemon, as if it was an empty MAIL FROM (bounce). Not RFC compliant, but neither are the idiots that send it.
I run mail systems professionally for others and I have my own little domains. I use SPF, and for my personal domains use -all defaults. I played a minor role in a precursor idea to SPF (the "Designated Sender" protocol.) I have tried to investigate whether that claim (or ANY positive claim about SPF) is fact both directly with systems I manage and by seeking out all of the data I can find, and have been looking for such evidence for a couple years now with little success. I have never been able to find any convincing evidence that what you claim is true, although many people have claimed it baed on hypotheticals. If you have any hard data , I would sincerely love to see it.
Here's a short version of the message you are replying to, since you clearly missed the point of my long-winded version:
Systems that generate bogus bounces are obsolete by design. They are extremely unlikely to be looking at SPF and are unlikely to do in the future so except as part of redesigns that would eliminate the bogus bounces without SPF. SPF provides nothing in the area of reducing bogus bounces that can have a significant effect in a wisely designed modern mail system.
Rather than having fewer systems generate bogus bounces, SPF can be used in a marginal way to identify situations where a bounce should not be sent vs. those where the message at least seems to be not have a forged sender. In other words: to assure bounce quality rather than trying to re-architect a system to reduce them. That's more a matter of theory than practice, but it COULD be done. I've not seen any sign that a detectable number of mail systems ARE doing it.
The first sentence is demonstrably true, although that number remains very small. The second claim is not supported by my own testing (I have some very heavily forged domains that I have used to test the hypothesis) but I am always eager to see hard evidence of something actually working to drive away forgery.