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 :)
At least this is one area where MS will have a real problem using their monopoly to enforce a closed standard. A solution that doesn't work for people that don't use MS software just isn't going to fly.
Having done work on (opt-in) HTML newsletters for clients, I know that email clients used are really varied - more varied than web browsers for instance.
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
I've had the unfortunate experience of attempting to generate XML using Microsoft's MSXML object. What a piece of crap! In an attempt to completely abstract the format, the objects are obfuscated beyond reason. Even the simplest things require ridiculous complexity: just to escape-out special characters requires instantiating a new "entity" element in the middle of the text string element.
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!
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.
That's the simple reason why, every time I hear about Microsoft doing something with XML -- like this proposal to use XML as part of email identification -- I cringe in ph33r.
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
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.
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.
I do believe this is one area we have to really keep an on eye on M$ in. Do they really want to stop the spam or is it just PR. They have the browser that doesn't block pop ups and on a default install of windows Ad-Aware will find things it considers an issue right after the default install.
This may just be a PR issue to show people they are pushing for it. When they implement something like this will they put their own hooks in it to allow what they want???
M$ really needs to be kept an eye on if they do this.
Evolution or ID?
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"???).
That still has the same problem as every other C/R system. In order to GET that phone number, presumably every email is responded to by a notice to call that phone number. It still bombards the poor shmuck whose email was forged with C/R requests.
... 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.
On a first reading, I thought the ideas seemed quite sensible. One problem they did address in an interesting way was that of people with several email identities. One of their suggestions is that whoever is hosting the incoming email provides outgoing smtp services too, which would be a change from the (outdated?) idea that one should always use the "nearest" smtp server for all email. Though ISPs who currently block outgoing port 25 (such as my University!) would have to think again.
N.
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.
In General Ackbar's legendary words'It's a trap!'
I guess the Joe-Jobbers will be hard at work trying to find all the ways of spoofing SPF.
Zombie writers will be in even greater demand from the spam factories.
Apart from spammers using zombified users email accounts, are there any other possible ways around SPF?
Having read the executive summary and skimmed a few pages, the general precepts make sense.
At the very least, the transitional phase of mass implementation of SASL or similar (which IMO should be mandatory for mail servers anyway) is a Good_Thing_(tm)
Granted it will take a lot of time and effort for the second phase to be reached, but anything which cuts down on spam gets my vote!
smile, it makes everyone else wonder what you're up to
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.
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
because the Sendmail sender verification proposal (mentioned here) relies only on already existing tech (Domain Keys, mx records, and smtp auth) thaty is already incorporated into the vast majority of MTAs, it does not really make much sense (from a users, or a non-microsoft, point of veiw) to create a seprate and more complicated solution (even if the license is rather innocuous).
I cannot help but think that continuing to allow senders that do not have a mx record for the sending machine to bypass smtp-auth for sending messages will fail to curb the spam problem, as it fails to tie the sent mails to an actual domain, and it allows (encourages) ISPs to restrict mailing through their email services only. With smtp-auth, it is still possible to send using an smtp server connected anywhere on the net, which allows accountability, but also makes it more possible to identify those providers who are allowing their users to send spam.
Read, L
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').
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 a fact of life that MS Exchange lives in corporate environments but ISPs and everyone use sendmail (or a sendmail derivative) for mail routing over the Internet.
It's actually in MS's interests to work with sendmail on an open protocol to do spam filtering properly (whatever that protocol is ultimately).
Remember that TCP/IP is an open standard and MS supports TCP/IP open protocols like FTP, HTTP, POP3, SMTP, etc. already in their products so this is no different.
Gentoo Linux - another day, another USE flag.
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.
Isn't this likely Microsofts attempt to get everyone using passport of something similar?
Once they authenticate everyone using their anti-spam system, they'll be able to authenticate for financial transactions, etc...
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...
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 think "do we want XML" vs. "do we want a series of header fields" is asking the wrong question. It's the schema that's wrapped up in the XML or fields that's important.
XML is great for expressing tree-like data structures, where as the "field-name: field-body" approach is probably better for expressing linear data. If you look at a schema it is usually obvious if XML is being used just for the sake of it, and parsing SPF as it stands is trivial.
Companies with an "embrace, extend and extinguish" mentality towards standards can leverage XML by using it without any formal machine-processable schema (DTD, XSD or RNG), whilst all the while insisting it is "standard" because it uses XML. Look no further than WordML for an example of Microsoft doing this.
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
No responses! Compare to SPF:
Here is the real reason Microsoft had to publish their Caller-ID spec now!
Before replying with "those 7500 domains are tiny", AOL is publishing a SPF record NOW. Microsoft is not publishing their own Caller-ID record yet.
PJRC: Electronic Projects, 8051 Microcontroller Tools
This is because you don't understand SMTP.
The Sender entry in the headers is often added by MTAs as the value in the SMTP envelope's MAIL field. This is the same value that SPF validates against.
Just because you don't understand SMTP and SPF is written in RFC language does not mean that Caller-ID is better. The XML in DNS TXT records is a big deal. The fact that with Caller-ID you have to validate after DATA is a big deal. But you won't understand these issues if you don't understand SMTP.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
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