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."
they did it! yay!
http://www.trustedsource.org/query.php?q=silverpo
http://groups.google.com/groups/search?hl=en&q=si
...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?
More MS FUD about being open, yet MS has never yet shown themselves to be anything but selfinterested proprietary money grabbers... Okay, yes, that sounds vaguely troll-like, but lets be realistic (no smoke without fire) and say, we really need to see genuine advances on the part of MS to believe anything they say, or that others might say nicely about them.
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? Just sounds like more FUD to me.... call me cynical, but I don't like when my OS calls home and does other things I don't want it to. When you count the brass tacks, this is just more propaganda
Support NYCountryLawyer RIAA vs People
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.
Is MS actaully doing something right?
/was available for Mac computers) that they would want to sell as many copies as possible. I mean think about it, if a company is not using windows you are not making money. So sell them Office software instead, yes they could use an open source alternative but also offer or beter yet bundle support with your apps.
Personally, I don't see why they don't make their addon products available for open source platforms. It would seem to me to be common sense to support UNIX / Linux (seeing as how office is
Maybe they are "testing the waters" by "donating" to open standards and opening up API's. Or it could all be a big PR stunt, but i am hopeing for the former because compitition is always good (as long as it is somewhat fair anyways).
To err is human; effective mayhem requires the root password!
So instead of the usual "embrace-and-extend", now it is donate-(wait for it to become standard)-and extend? :-)
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.
Please come home, all is forgiven.
Love,
http://www.gnaa.us/
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.
The SenderID it doesn't have any importance when a lot of spam is coming directly through OutLookExpress of the infected users. We will have spam with SenderID ...
Regards
Webmaster's Talks
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 ----
Microsoft has changed and is getting more friendly to the Open Source movement every day. Funny thing is /.ers continue to state 'they are evil greedy money grubbers.' Well they are a business and they are finally seeing that maybe there is some profit in working with and not against the open source community. Oh, that's right, this is communist slashdot where those who want to make a profit is somehow evil. The slashdot sheeple believe in the matra "Information wants to be free" so all music, movies, software, etc. should be free and open. Basically they don't want to pay for anything. Fuck, they would steal all of their hardware if they knew they could get away with it.
/. mindset is at.
Naturally, this post wil be modded down into oblivion as the slashdot sheeple don't waqnt to debate the points, but rather censor the posts as they know almost all slashdot sheeple have a threshold of at least 0. Funny thing is the posts that state "Open Source rulez, All closed source drulez" comments, even when posted exactly like that are modded to +5 insightful, informative, or interesting. That shows where the
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.
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.
You my friend, are an outright liar.
Before being seduced by the dark side, Meng Wong promised domain holders a way to prevent their domain being forged in SMTP. He promised MTA operators a way to reject on forged MFROM during SMTP. That was why tens of thousands of SPF records were published prior to the formation of MARID. Again to counter your flamebait, SPF certainly did have commercial support although it didn't maintain high-level commercial backing. MARID was disbanded due to lack of consensus specifically when Microsoft refused to compromise by making it's PRA patent license compatible with open source licenses. Finally, an appeal to the IAB about removing four characters ",pra" from an RFC to make SenderID technically compliant with hundreds of thousands of published SPF records was (arrogantly) refused.
This next gem is typical of the hostile and offensive slurs made within certain working groups to discredit outsiders...
Nobody needs experience of the standards process to understand how Microsoft do business. The insistance on incompatible reuse of spf1 records by SenderID was deliberate and malicious. The PRA patent license terms were deliberate and malicious. Then there was the unworkable proposal for storing XML records in DNS and the very way Microsoft successfully bamboozled the entire process - by claiming they wanted a user visible solution.
A technical working group conviened on the subject of "MTA Authorization Methods In DNS" should not be concerned with "user visible" client-side solutions like SenderID. Don't think you're not going to be called on the euphemism "reasonable compromises" in reference to technically un-sound proposals either. The fact that the reuse of spf1 records for SenderID made it to RFC status, despite an appeal, strips the IETF of any and all crediblity in my eyes.
Note for casual readers
Parent comment is pure flamebait. Follow the money. Funding for the IETF is provided by ISOC, to which Microsoft is a major contributor. This is the heart of the matter, the IETF is not an impartial or efficient technical standards body. There's the saying about the internet routing around problems and right now it looks like it's starting to route around both the IETF and (ironically) the W3C.
FTA: "Founded in 1975, Microsoft is the worldwide leader in software, services and solutions that help people and businesses realize their full potential."
Most of the article is plain old microsoft propaganda.
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.