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!
Maybe they feel kind of guilty since the majority of spam is relayed through trojaned windows boxes? :-)
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.
Honey, I shrunk the Cygwin
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."
Spammers are just going to use a DNS server to tie the domain to the IP.
If I find an open relay in China I simply register a domain, use a DNS server (plenty of those around) to point the domain at the open relay and then fire away. This supposed "verification" is just going to check the domain and the domain is going to report that the IP is "legitimate."
For awhile I had linux.icarusindie.com pointing to the IP of MS's web-site and windows.icarusindie.com pointing to linux.org's IP.
MS's site fixes the url when you click a link on their site while linux.org kept my URL in the browser no matter where I went on the site.
Ben
Work Safe Porn
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.
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.
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.
I say let them do whatever they want.
If nothing else it will encourage us to come up with our own standard that's open and better.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Doesn't Microsoft hold a patent on their 'Caller ID for email' specification? Are they dedicating the patent as part of their submission of this spec to the IETF?
Or is this Microsoft's attempt to not-so-subtly obtain a lock-in on email?
This question must be VERY CLEARLY answered before anyone moves forward.
Tired of FB/Google censorship? Visit UNCENSORED!
#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.
Linux is very user friendly. It's also very fussy about who it makes friends with.
Good, inexpensive web hosting
Not to say that there is not cause for concern or need for extreme watchfullness but a stable net profits everyone, reducing spam to a manageable level in which a bulk nugget might even catch the light is profitable to everyone concerned, even the legit bulk mailers. I think the answer is to build an authenticated mail infrastucture at the tier-1 peering level, working with the DNS managers, and system and provide link points to the existing system...You could receive authenticated mail from a validated sender, marked as such, and continue to receive un-authenticated mail should you choose to. Gradually legitimate sources will migrate to the authenticated side, if it is worth snot that is, and the 'evil' spammers will be left dishing traffic that can be ignored or dealt with as user/provider see's fit. Much like they have done with news feeds today. The key issue I think if a wild user land style net is to survive, is to both let and force the businessess to assume much of the burden of the infrastructure and deal with the costs behind the scene. IE the big banks and VISA to make and provide a financial network, and allow vendors to establish a presence at their expense. Their motives are crystal clear, they are federally regulated on the use and disclosure of information, and they have a relatively good track record on security. I'd trust a bank or a casino to manage security and money long before I'd trust the government or another private interest. The thought of the UN managing somthing like that scares me silly, they'd decide it was in our best interest and for humanity as a whole to be 'gattica' marked or somthing equally pernicious. Oh well Cheers all and TGIF :)
Salute to the Flames, MY HATS OFF AND HEART STILL WITH THE SHARKS, way to go guys, next season !!!
5 year season ticket holder and true believer
errr....umm...*whooosh* *whoosh* Is this thing on ?
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
And then they sell telemarketers the privilege of having that software block selectively reinstated, and THEN (get ready to really feel used), they recently introduced a new "service" that identifies all callers (i.e., removes the selective blocking), which you can purchase for a nominal monthly fee. I hear the internal codename for this "service" is "Guido." Don't you feel safer with all this "Protection" they're offering you?
Today's Sesame Street was brought to you by the number e.
This message is intended for organizations that do a lot of forwarding, like acm.org and ieee.org, as well as the vanity domain providers.
During the development of SPF, we have tried very hard to accommodate your perceived concerns, because the biggest problem with SPF-against-2821, as many people have noted, is that it breaks forwarding. But your perceived concerns might not be your actual concerns.
It would be really great if the people who might be hurt by what we're planning could get involved in the discussions, so we could ask you whether we guessed right, and if there are better ways to reduce your pain.
So, if the postmaster at acm.org happens to be reading this, or if anyone reading this knows the postmaster@acm.org, please ask them to subscribe-spf-discuss@v2.listbox.com
Postmasters at other places like acm.org too.
Thanks,
meng
from Redmond