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."

Comments

Re:Imagine when Hotmail gets this

[leerpm]

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.

It is called defensive patenting. There is nothing wrong with applying for a patent on this. We do not want another Eolas, where some other company that produces zero innovation gets a patent on it instead, and puts a strangehold on the industry. While not perfect, Microsoft has been pretty good about not going after other companies with frivolous lawsuits over patenting issues. Since the USPTO now seems to accept pretty much anything, companies have to apply for patents on whatever possible, so that they have something to use to defend themselves in the future.

Re:XML... in its place.

[Hard_Code]

Sort of. You don't REALLY need a DTD - you only need one if you are validating the XML. XML can still be used as a generic ad-hoc hierarchical data format... of course you'd only want to do so because by now XML parsers are pretty ubiquitous and it makes it as good a choice as P-lists, or any other ad-hoc format.

Re:If Microsoft cared about SPAM...

[jfengel]

It shouldn't have taken so long, but they claim that it's coming.

Re:two things

[blowdart]

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.

I don't think so. What people can find out is what IP addresses are valid when sending email from a domain. Nothing more. All they are doing is a lookup on the connecting IP against the FROM: domain. Hell, that information is in your headers anyway. (Well unless you're using a remailer)

Re:Danger! Read the fine print!

[DHam]

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".

What is a PGP signature?

[stefaanh]

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.

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 ... but is should be easy to hook it up anything.

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.)

Re:MSXML experience

[the endless]

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.

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.

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.

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.