Slashdot Mirror
Microsoft Submits Email Caller ID to the IETF
NetWizard writes "Following on the heels of Yahoo submitting DomainKeys, Microsoft decided to submit their "Caller ID" anti-spam proposal as a draft to the IETF. This proposal tries to tie in IP addresses to the domain of the sender just like SPF does. To make things even more interesting, looks like SPF and MSFT's Caller-ID proposals are merging. On a related note, Yahoo submitted an IPR disclosure for DomainKeys to the IETF."
First off - I'm a great fan of XML - as a configuration specification format, it's great and I love it. I don't however think it's the solution to every problem - the BIND format is inherently non-XML, why not (if the proposal is to specify outgoing nameservers in the same way as we currently specify incoming nameservers) simply have an MO (Outbound
One of the reasons I love XML is that the configuration can later be extended without impacting on any parsers that only read version 1.0. Perhaps this *is* a good reason. Or perhaps it's a way of getting a standard out there that's easy to 'embrace and extend'. Paranoia? Perhaps.
I do think it's a nice idea though, and it will stop a lot of spam - it will also make it far more valuable to 'own' the mailserver, with all of the implications thereof...
Simon.
Physicists get Hadrons!
What we really need is a solution that is completely non-proprietary. A solution that no one company has any ability to control.
... )?
Can you imagine what the network would be like today if Microsoft (or anyone else for that matter) had patents that allowed them absolute control over any of the common protocols (telnet, ftp, http, smtp, pop3, imap,
Well, that's where the IETF comes in. Most Internet standards (or other standards for that matter) have been proposed by companies; that doesn't make them bad.
Note that the IPR filed by Yahoo is the clean kind: it says "we might have a patent on this, go ahead and use it for free as long as you don't sue us."
This pretty much translates to "keep some S.O.B. from trying to running this past the patent office's feeble checking and suing everyone."
That's fine. The goal of SPF is so you can't send mail claiming to be from paypal.com, or citibank.com. It isn't the end of all spam.
From RFC 1531, the IETF definition of DHCP, authored by Ralph Droms, who was then at Bucknell University:
5. Acknowledgments
Greg Minshall, Leo McLaughlin and John Veizades have patiently contributed to the the design of DHCP through innumerable discussions, meetings and mail conversations. Jeff Mogul first proposed the client-server based model for DHCP. Steve Deering searched the various IP RFCs to put together the list of network parameters supplied by DHCP. Walt Wimer contributed a wealth of practical experience with BOOTP and wrote a document clarifying the behavior of BOOTP/DHCP relay agents. Jesse Walker analyzed DHCP in detail, pointing out several inconsistencies in earlier specifications of the protocol. Steve Alexander reviewed Walker's analysis and the fixes to the protocol based on Walker's work. And, of course, all the members of the Dynamic Host Configuration Working Group of the IETF have contributed to the design of the protocol through discussion and review of the protocol design.
DHCP was developed in the IETF. Microsoft was an early adopter.
Either in terms of money or market share?
They would not be doing it if it did not help them in one or both of those areas (and directly as opposed to indirectly, if at all possible)
Microsoft is not a charity. Even when they do give money to charity, they have reasons that have nothing to do with simple kindness.
You're wrong. Sometimes they do things just because.
However, in this instance, they have MSN, Hotmail and Outlook. It'd be nice to have all of those services and apps spam free - it'd make their customers (who are complaining loudly about spam to them) happy.
Coming soon - pyrogyra
Both implementations have problems.
With Microsoft's, it's just a matter of spoofing IP addresses also.
Yahoo's idea is better, but it's worthless unless EVERYONE is using it. As long as there's one server out there not using it that you wish to receive e-mail from, you'll need to allow legacy e-mail, and thus spam through.
Did it ever occur to you that Microsoft may be pushing for this because because they have some outstanding computer scientists working for them that want a name for themselves? Merging with SPF sounds like a great idea. The proposals will be inter-twined, and neither company will have absolute control over it. It will make Microsoft look good. That's all.
And even if Microsoft doesn't merge with SPF, would this be a bad thing? Some of you with tin-foil hats might think so. But I think to say Microsoft will make the servers reject e-mail from non-Microsoft servers is a little extreme. What will happen is there will either be a standard that everyone can use, or there will be more than one thing and servers will have to implement all of them, in it's e-mail verification process.
It seems like a lot of people who post here are from Red Hat.
By the way, I don't support mass adoption of C#, I would like to see the OSS community make their own bytecode environment that is comparable to Java. I do think Mono is a fine platform for developing OSS/Free software, though.
Lots of industry folks (MSFT, Dell, etc) have been reporting lately that a significant portion of their service calls come from either spam or spyware.
Cutting service costs will definitely help the bottom line.
Microsoft cares about spam for a reason: Microsoft owns Hotmail. Any technology that helps get rid of spam increases the value and usefulness of e-mail overall. And if everyone uses e-mail more, then that includes Hotmail users. (If Hotmail can take advantage of some of these technologies before its competitors, then that doesn't hurt either.)
This isn't the only thing Microsoft is doing to combat spam. They have a number of PhD's working on the problem at MSR. For the web page of just one of them, see the following:
http://research.microsoft.com/~joshuago/
So relax! Microsoft realizes that improving the computing experience of their users is in their best interest. Fighting spam is just one way to do that.
#1: They are patenting the idea.
#2: Their license is apparently not compatible with the GPF license.
If clueless idiots start blocking based on the lack of a Microsoft patented DNS record, you will not longer be able to use an open source mail server.
Step 3: Profit!
Microsoft certainly has plenty of underpants gnomes.
which might be part of why there are SO FEW good managers for named (the binary via the config file) and DNS (the data within zones). There are things that WANT to do it, but they are few and far between.
Me? I find that XML is often a hammer and oh, look at all the nails! This one is a nail.
Mostly, you're right. It's GREAT for many config files. It's easy to parse, it's non-binary, the structure is self describing and it's EASY to present forms for managing something via web or curses or GUI.
And that's a win.
I'm tired of writing tools where each tool has to be intimate with the details of a config file and application. I'd rather be familiar with the DTD and use the "meta data" available. It doesn't make apps automatic, but it sure makes it easier to manage them.
A stylesheet can easily convert managable XML data file into an inetd.conf file. (trivially easily).
And perl/php/java can easily read in and write out XML files. My program just has to deal with the data structure that's been read in.
Now, that said... XML is wordy and large.
DNS (not BIND, DNS) struggles with large anyway. It's an ugly ugly hack/misuse to shove XML into several TXT records. Anyone remember trying to get PGP keys into DNS? We should it would be a great way to distribute them at least internally (where we controlled all the DNS servers). But TXT records won't HOLD a 1200 character blob.
Doh!
Again, we're looking for an LDAP type solution or at least in need of some infrastructure tools beyond DNS's hostfile replacement capabilities.
This whole CA thing is out-of-wack IMHO. We need free CA's that can accomplish the same goal, namely verifying the integrity of part of certificate information. The theory is that if you used a credit card to purchase the certificate, then at least the info relating to your CC is valid. So, how do we fund free or low cost CA's and how do they verify that you do legally exist and are reachable via valid contact information?
It is possible, and much more feasible, to simply use public keys without digital cretificates. This is the old fashioned approach where the host itself verifies its own signatures. Hosts can verify they actually sent the email.
I'm not sure what this accomplishes though. If a PC is infected to become a spam bot, then why wouldn't its SMTP server sign its outgoing messages? How does it know that one of its clients is infected? And, if it signs the messages, then receiving email servers will validate the signature without a problem. Thus, spam will still get through because it is coming from a trusted client through a trusted SMTP server.
Open Standards Portal