Slashdot Mirror
Microsoft Releases 'Caller-ID For Email' Specs
gfilion writes "Microsoft has released a draft specification for Caller-ID for email, 'to address the widespread problem of domain spoofing' - the concept is similar to SPF, but is using XML. There's already an Caller-ID to SPF converter in the works. A few weeks ago, Microsoft discussed compatibility between the projects with Meng Weng Wong (SPF's project leader), but most SPF users are against using XML, so nothing has come of it thus far." We recently covered a brief article mentioning Microsoft's anti-spam work, though this is a clearer indication of their intentions. Update: 02/26 21:36 GMT by T : NewsForge is carrying a brief article with FSF counsel Eben Moglen's take on the draft; Moglen says it is "encumbered with unclear and unnecessary patent license claims."
While I acknowledge that XML is great for some things, why is it that it gets used for almost everything nowadays? Damn buzzword-dominated market...
Ok, I'll be quiet now :)
Whats to stop a spammer from signing up for a free email account with a false name, blast out a few thousand messages, drop the account (it'll be closed anyway by abuse), wipe hands and repeat?
True, I see how this may help stop some spam, but it also means (if I understood the article correctly) that everyone can find out where I mail from... and in some instances that could be a problem too.
Everything in the world is controlled by a small, evil group to which, unfortunately, no one you know belongs.
Microsoft is one big player in the email world through their Hotmail service. They probably serve more spam to more places than any other single mail service. As such it makes sense that they would want to be at the forefront of spam-elimination technologies. They ought to be applauded for their initiative here, as well as their cooperation with SPF and Sendmail.
However, it disconcerts me that they are also applying for a patent in this area instead of engaging the community through a consortium-like committee that could share the technology across the board unencumbered by licensing fees. The specter of Hotmail becoming a proprietary mail system requiring foreign mail servers to run Microsoft-licensed "Caller-ID" to interact with Hotmail is a very legitimate concern.
I have been pwned because my
Caller-ID for email will help prevent spoofing, but will only increase spammers use of zombies. I wonder if increased exploitation of Microsoft OS weaknesses (to create spammer platforms) will have a long-term detrimental effect on Windows or whether it will hasten adoption of Trusted Computing? I wonder if Microsoft wants ISPs to become so sick of zombie boxen that the ISPs will prohibit all but a few chosen OS options (read the lastest version of Windows) for connection to their networks.
For a very well-entrenched provider, making everyone sick of you old product is a good way to force them to buy your new product.
Two wrongs don't make a right, but three lefts do.
if it will mean I have to pay fees to Microsoft to get my domain signed, I'd rather continue filtering out spoofed-bounces, thank you.
Interesting how instead of supporting a perfectly sound project that has been going for a year, everybody seems to have to come up with their own little *patented* scheme.
RTFA - Microsoft proposes a standard which any vendor can implement and provides a license for its use on the website describing the process. There sis nothing client specific about the implementation.
Parent is +5 interesting? Could anyone who moderated it up provide a reason other than they're bashing MS, that's +1 baby!
I hate XML, and a quick google reveals:
XML sucks = about 215,000
XML rocks = about 174,000
I'm pleased to see I am in the majority - I thought its buzzword status would have rated it higher.
They would have allowed a user to disable a the javascript popup function in the browser. Instead we have to rely on bandaids like googles toolbar to block popups from websites.
(From Microsoft's license.)
So by building support for "Caller ID for Email" into your software, you suddenly give Microsoft an unlimited license to use and sell it. And, in fact, not only Microsoft, but everyone else who writes software that supports "Caller ID for Email."
There is a word for this: Insane.
No thanks. I'll stick with SPF--especially since the two are essentially identical, just a slightly different parsing format.
It's hard for thee to kick against the pricks.
They already have systems that do this [challenge-response], you know. This doesn't require any changes to standards; but it does require that the sending user be clueful - and given how quickly Netsky.C spread, I think that's a hopeless cause.
In the US at least, caller-ID is not a challenge response system, it simply displays the originating phone number - and ONLY if you haven't requested that your number be hidden, and only if you live in an area that supports it.
So, what lessons can we carry from this fact to MS's suggestion of "caller ID" for email? 1. We'll still get emails that are unauthenticated, because it will take a long time for folks to upgrade MTAs to manage this - after all, there are still open relays - and 2. someone will figure out some way to sell a solution to get past the authentication system so blocked spam senders can still get through (can you say "sales@viagra.hotmail.com"???).
RTFA - Microsoft proposes a standard which any vendor can implement and provides a license for its use on the website describing the process. There sis nothing client specific about the implementation.
I did read the article. But MS has a history of breaking standards to create customer "lock-in", and also trumpeting open standards when in fact what they finally implement isn't open at all (Office "XML" for example). What I'm saying is that, in this case it would be difficult for MS to do that because email client software is very varied.
... because the performance is crap. This is true on my pc (with any parser you care to name - i've tried it) so what it'd be like on a mail server handling x thousand messages a minute I have no idea.
XML is great, but only when the underlying data is sufficiently variable within a pre-defined schema and where throughput is not an issue. It's not necessary here.
sean.
And I still haven't figured out how to make the thing give me a CRLF at the end of each element. No, XML doesn't require the whitespace, but it would have sure made it easier for my clients to read the file!
Tell me about it. My favourite part is when you try to load one of their MSXML-generated files into their Visual C++ 6.0 product and it bitches about lines being greater than 2048 characters long and how it's going to shove random line breaks in the middle of tags.
Thanks, MS!
Registering accounts later than some other chrisb since 1997
Did you consider that e-mail are used outside the US? I am certainly not going to pay a trans-atlantic call each time I want to send an e-mail to a new guy in the US. What about people that don't speak English? What about people who don't have a phone, or don't have a number on a system that supports caller id? With the advent of IP phones, this would become more and more common.
Not sure if this is mentioned in the .doc, but _ep.microsoft.com already appears to be doing this:
> <a>207.46.71.29</a><a>194.121.59.20</a><a>157.60.2 16.10</a><a>131.107.3.116</a><a>131.107.3.117</a>< a>131.107.3.100</a>" "</m></out></ep>"
_ep.microsoft.com. 1H IN TXT "<ep xmlns='http://ms.net/1' testing='true'><out><m>" "<mx/><a>213.199.128.160</a><a>213.199.128.145</a
This is a good idea, and we (tinw) has discussed this many times before, and various implementations already exists (that is - verifying the sender domain, not the specific MS implementation).
Now, what bothers me is this line:
Microsoft believes that it has patent rights (patent(s) and/or pending applications(s))
Given the latest stories on how easy it is to patent everything "over there", I am pretty sure MS is granted this patent. Now I don't know about you, but this geek ain't licensing nothing from MS.
Could anyone who moderated it up provide a reason other than they're bashing MS, that's +1 baby!
Well no. They can't comment if they moderate now, can they?
Ray
In the license Microsoft grant implementers there is the following nasty clause:
If you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the following notice be prominently displayed in all copies and derivative works of your source code and in copies of the documentation and licenses associated with your Licensed Implementation:
"This product may incorporate intellectual property owned by Microsoft Corporation. If you would like a license from Microsoft, you need to contact Microsoft directly."
Isn't this incompatible with the GPL?
Rich
I looked into SPF, briefly, and it doesn't seem to solve a problem I have...
I have various (virtual) users (~20-25) on my domains.
These users use both my SMTP server (when using squirrel mail, or (ssh-)tunnelling to the SMTP server, itself), as well as their local ISP's mail server (sympatico, videotron, etc)... My SMTP server doesn't relay from anywhere except localhost.
So, in order for SPF to work, I need to allow email from my domain, and these ISPs.
The ISPs are large, and when an email virus goes around, mail is undoubtedly sent "From" me (actually from/by outlook users with me in their address books), through these ISPs' SMTP servers, making SPF useless.
Am I just missing something?
S
No, it is not insane. It is called cross-licensing. They are saying if you want to use this technology, then you agree that you are not going to come back and sue Microsoft (or any other licensee too!) for patent violations relating to this implementation. This is a good thing!! They are protecting themselves.
So by building support for "Caller ID for Email" into your software, you suddenly give Microsoft an unlimited license to use and sell it. And, in fact, not only Microsoft, but everyone else who writes software that supports "Caller ID for Email."
Absolutely not. There is something called copyright law. Microsoft or any other company cannot just go and resell your software on their own terms. The license just means you cannot sue them for patent violations when they choose to build software that implements technology similar to yours in this area (provided you had obtained additional patents relating to this 'Caller-ID').
just to escape-out special characters requires instantiating a new "entity" element in the middle of the text string element.
Maybe that's the "right" way to do it, but I highly doubt that you cannot set the value of a text node to a string that contains an entity (i.e., "this is an ampersand: &"). That would be the more direct approach.
And I still haven't figured out how to make the thing give me a CRLF at the end of each element. No, XML doesn't require the whitespace, but it would have sure made it easier for my clients to read the file!
First, you could have them read the file with Wordpad or just about any text editor other than notepad. And BTW, why are you complaining about MSXML not generating CRLF? You DO realize CRLF is a Microsoft-ism and not "standard", right? So you're complaining about MSXML generating text files in a manner more in line with the way every other system does it. Baffling...
But the worst part is that I *succeeded* in using MSXML. Now, if I wanted to go back to just writing a text file (which I do!), I can't -- my code is tangled up in the objects to the point that it would take a complete rewrite.
I've got news for you -- every decent XML parser library requires you to manipulate the XML tree in an object-oriented manner! It's called the Document Object Model for a reason -- you're not manipulating raw text! You can go ahead and do that if you like, and we'll see how much "easier" that is for any project requiring more than the most basic use of XML.
Mods, get a clue. The way the MSXML library handles XML is not unique in some "Microsoft always makes crap" kind of way. Every decent XML library handles XML the same way.
Actually, it doesn't say that. The important phrase is "Necessary Claims" and the word "reciprocal" gives a good hint too. This is just a defensive patent licence. It says that Microsoft won't sue you for breach of patent for implimenting the standard or dealing in implimentations and you promise the same to Microsoft and everyone else.
It is NOT a copyright licence to Microsoft to use and sell YOUR implimentation. It only affects you if you hold patents which Microsoft or someone else infringes by implementing this standard. It effectively sets implimentations of this standard in a "patent free zone".
I say ignore them.
Microsoft has never been interested in helping the community but rather wants only to further its own dominance of the market. When did they start being philanthropic?
What's to say in a few years time when everyone is relying on this that they don't pull some stunt and start charging people? Do you know enough about the law to say they couldn't?
Anyway their record on enhancing email is not good. I knew the first time I saw the ability to embed HTML and * SCRIPTS * into email that the virus writers would have a field day. I mean, what complete arseholes to allow code to be executed when someone just *reads* and email. It beggars belief!
If they are serious they could assign their patents over to the FSF and then we'll consider it. I bet they won't.
Shouldn't widespread adoption of PGP be the best solution? For me any implementation of PGP sig IS a Caller ID, only it is not XML, but it could easily be wrapped.
... but is should be easy to hook it up anything.
IMHO MS is reinventing a wheel, or trying to own it.
So, if everybody should become aware of the sense of a PGP sig, maybe with a service like "pgp://pgpserver.domain.tld" the problem is on its way to its solution... It shouldn't be part of SMTP sendmail or
Maybe the idea that mail could potentially be completely private (read:encrypted) is not that appealing to everyone.
So, tell them you read it here first. (Or point me to a similar idea.)
--------
* Sigh *
It's is not a data format.
It's not a framework.
XML is a badly-formed roman numeral.
It should probably be written "MXL".
But even that might be a problem. You might need to use the Unicode Standard symbols: 2169,216F,216C
I have misplaced my pants.
I use a locally running postfix SMTP server on my laptop to send pretty much all of my email. Microsoft's proposal doesn't address this: of course, my laptop gets various IPs. I cannot use the SMTP server provided by my organization, as they firewalled it... With the MS proposal, I will have to go for VPN or talk to my sysadmins about smtp-auth -- and lose my independence...
Er... in that respect, Microsoft are following the standards, because that's how it's done with the W3C's Document Object Model. If you have a problem with it, you have a problem with the DOM, not with Microsoft.
Again, that's your fault, not Microsofts. Either live with it, or split out the XML-generation code into a separate module. The world and his dog has long since learned to separate out logic code and database-access code so that it's possible to change DBMS by just rewriting the database-access module rather than the entire application - exactly the same thing applies with XML.
Like caller ID worked for the phone system. About 90 percent of my calls were either "Unknown" or "Private Line", and some action was still requried on my part to respond to the ringing phone.
I don't have facts readily available to back this up but I'll assume somebody made money off caller-ID, as will Microsoft will attempt to do with their new "standards".
-Phil
Shoot questions, first ask later...
Basically, it's a very poor re-implementation of SPF, with all of SPF's disadvantages and none of its advantages.
Under the MSFT scheme, the TXT records are verbose, likely requiring several records where SPF will probably fit in one. They have a hare-brained scheme to parse Received: headers to get around certain problems. Their scheme is absurdly complex.
And neither SPF nor MSFT's scheme do anything about spam coming from <>, cracked Windoze machines, or "valid" throwaway accounts. They also make forwarding more difficult than it should be.
I wish you would learn something about existing mail standards-- like their colossal drawbacks. SMTP is entirely "a simple text format", and that's one of its biggest problems. We have all kinds of lame hacks for mailing binaries around and handling attachments. Nearly everyone who writes a mail client writes a mail parser and a composer. Not just a formatter, or presentation-level stuff-- basic goddamn parsing and composition.
You don't seriously believe that any format that is newline-dot-newline-delimited is a good one, do you? SMTP is a relic, all the way down to the message format. I hope to god someone eventually succeeds in dislodging it.
And that is why Microsoft is using it I'm sure. They have a bunch of nice GUI tools that parse XML, so anything they do now has to be XML.
It's the same as the way they do email. If I switch to source edit view, my simple text message (e.g. Got It.) balloons into ten lines of generated HTML gobbledygook. Yes, I really need to specify the font for *each* line...even the ones that are blank.
I really hope that the standard is not set by MS. Something very simple (this is who can transmit for this domain) could turn into something ugly. I can write SPF declarations by hand. Chances are that their XML declarations will be twenty times as long and will need tools to create them. Yes, the XML parsing tools are ubiquitous, but a simple format doesn't require a parsing interface to feed you info. I see no reason not to make a human readable interface.
Colossal drawbacks to text? LOL! It is a feature. You could say the same for most internet services. There are no standard client API's for FTP or Telnet or most other services either. Has that stopped their widespread adoption? Has it made them any less useful? No.
I am not concerned at all of people like you who make the internet groan under the weight of 20MB excel files wrapped in proprietary XML formats. MIME has done enough damage. Maybe the Standard should be a Microsoft (C, TM) paperclip icon that does a dance while he speaks your message in one of a hundred supported languages.
an ill wind that blows no good
You said it! I'm sure we'll all regret using a standard format for hierarchically arranged tuples of name-value pairs. I only have to use this type of data in maybe 99% of my projects.
Nothing wrong with agreeing. Agreeing on a standard that's cruddy will bite you in the ass. There are many, many standards, and most of them are cruddy.
And "name-value pairs"? How do attributes figure into that? Well.. Cruddily, that's how!
Perhaps you're thinking of RDF (which has issues of it's own.. A lot..).
And the output files sure are difficult to understand if you've never seen any markup language before and don't have a file viewer that understands ASCII text.
XML allows for a lot more than ASCII.. Which is the reason a fully compliant XML parser is enormously bloated.
Instead why doesn't everyone just make up their own format that is uniquely tailored for the individual application? You can leave off the attribute names since the recipient of the data should just know what they are anyway. And you can use a binary encoding to really add efficiency to the process. And developers love the challenge of trying to figure out new data formats on top of interpreting the data itself.
Slippery slope? Or straw man? The latter. I never said no standard should be agreed upon. I would have preferred if it had not been something as complex and cruddy as XML. I even specifically gave S-expressions as an example that would be much simpler; you might note how that's not a binary format.
One day, ASN.1 was what XML is now (well, it still holds telecommunications and cryptography in its stranglehold). Do you propose we use ASN.1 because it's so well accepted and standardized and there are so many tools? Or do you recoil in shock at how bloated the featureset is, how convoluted the encoding, how shockingly incomprehensible the parsing process? XML is simpler than ASN.1, and XML is better than ASN.1 (except that ASN.1 has a cute way of compiling parsers from its syntax/schema language, which is a nice feature); but that does not mean XML is the best general purpose meta-syntactic language imaginable. It's not.
SCO employee? Check out the bounty