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."
Here is the origional
Evolution or ID?
When you run an email system that handles more email than hotmail and msn.com combined, then you can submit your own draft (get in line behind Yahoo and AOL).
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
I know that I'm just being stupid here but some history:
When callerID was invented, the phone companies were making money on two fronts: first, they charged consumers for the service (which eventually became free) and they charged telemarketters for an "Unknown" callerID listing. Money on two fronts.
It doesn't surprise me that Microsoft is behind this latest version of callerID for email. I'm sure that there's money in it for them somewhere.
Just kidding.
Life is the leading cause of death in America.
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,
Microsoft expects that when certain folks start needing new features
that are not expressible in v=spf1, they can publish their records
in XML and all the clients out there will be able to read those
records.
"certain folks" like Outlook developers, maybe?
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.
"They've already taken a stab at the video game industry, remeber? "
So... you're afraid Microsoft will take over email, but you've already noticed they can't make a monopoly out of everything they touch. I can't tell if you're karma whoring or if you've written a rather amusing satire of the way a lot of people here on Slashdot behave.
"Derp de derp."
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
From http://www.openbsd.org/lyrics.html:
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
Spammers can still use zombied PC's or throwaway ISP accounts to send out their spam, and they'll look good enough to pass the "caller-id" test.
I've thought about this problem some (although I'm not an email expert), and I believe that what is also needed is a way to throttle the email output of individual users (so that joeblow@yahoo.com can't send out thousands of emails a day). This would necessarily have to be done by each user's ISP; as a new user, only allow a few emails per day, and gradually raise the limit as the user gains trust (by not abusing his account).
The big problem with this approach is that every system that originates email has to cooperate. Those that don't can eventually be blacklisted by the rest of us, but it can only work if the big hosts like Yahoo, AOL, MSN lead the way. Also, this can only work if spammers can't forge the return address and/or origin of their emails, and the MS proposal seems to address this part of the problem at least.
Have you read my blog lately?
Why should people have to shell out $150/yr just to run an email server?
Or have to buy two certificates, one for the incoming mail and one for the outgoing mail (yes, you can't use server certificates for outgoing mail).
bash$
And what Certificate Authorities (CA) will your email server consider acceptable?
Any of them.
Two things need to work different from the current system for obtaining web server certs, which is primarily designed around enriching CAs and has a number of flaws when it comes to actually being secure (like, for instance, the look-alike name problem).
First, anyone must be able to produce a certificate endorsing an address as a "non-spam" address and have them publically published. Root CAs and an "email tax" are unacceptable for many, many reasons. A company could have a cert signed by their domain authority and sign off on each employee.
Second, trust must be non-binary (this is where GPG comes up short). People that endorse people that spam have their trust reduced. This is transitive -- people that endorse people that endorse people that spam have their trust slightly reduced. An email would be accepted if it is above some spam threshhold.
While not absolutely required, I would recommend signing on the client (and optionally signing on the server -- the benefit is that companies can quickly switch to a trusted email system without immediately transitioning and changing their clients at the risk of allowing people within their company to impersonate someone else if the company lacks authentication on outbound email.
Most people would probably trust a number of "root authorities" by default, like "ICANN" or the domain name registrars (though I'd guess that such folks would be trusted a relatively low ammount). They'd probably trust their business, which would sign off on businesses that they have business relationships with. This would not require much by way of user-visible functionality.
What happens if Bob's account at Acme Widgets gets compromised and he starts sending out spam? Bob quickly gets lots of certs saying "Bob is a spammer" from folks clicking the "this is a spam" button in their client. Bob's email quickly becomes ignored, and Acme Widgets is trusted somewhat less.
What if Acme Widgets' user-cert-granting system is compromised, and a spammer starts making new "trusted by Acme Widgets" IDs and spamming with them? Eventually, Acme Widgets loses their trust, and mail from their system starts bouncing.
The system could even be modified to avoid horribly blacklisting a company that is badly compromised once -- make such "this is a spammer" certs have a short lifespan at first -- say, a week. Exponentially increase this lifespan by default in clients. If a normally well-trusted domain sends out masses of spam once, they're only "offline" for a week. If they keep doing so, however (say, email security sucks at this place and the email server is rooted once a week), they are rapidly made unusable.
This doesn't rely on a single central authority, doesn't favor businesses over individuals, doesn't make an "email tax", doesn't not require a change en-masse (though people who haven't switched don't recieve the benefits of the system, and such a system becomes more useful the more people are in the system), does not inconvenience those who want to run their own mail server or forward (in fact, it facilitates folks doing exactly that, since they can sign things using their work certificate through their home certificate). The only drawbacks that I can think of are in increased CPU and network usage for normal operation (though the decrease in spam may more than cancel at least the network load out), and the folks who nobody knows or trusts may initially have trouble sending to people. The side effects are *positive* rather than negative -- people lose the ability to spoof email (why email is used as a business tool when it's so easy to intercept and spoof is beyond me), and a distribution system for signing keys could just as easily be used to distribute encryption keys, providing end-to-end content encryption for all users.
So many people seem adamant about converting DNS into some kind of addressing-and-securi
May we never see th
According to recent posts by Meng Weng Wong (author of SPF) to the spf-discuss list, the "new SPF" will incorporate features of Caller ID.
s tb ox.com/200405/0198.html
In general:
* The RFC 2822 FROM header will be duplicated in the RFC 2821 header. Mail servers will say:
MAIL FROM: <original@original.com> RFROM: <me@me.com>
* SPF rules (which were basically the same as Caller ID's) can specified in either text or XML.
* A new DNS record type for SPF will be used rather than TXT.
But don't take my word for it. Go read the posts here:
http://archives.listbox.com/spf-discuss%40v2.li
The radical sect of Islam would either see you dead or "reverted" to Islam.
> Microsoft has not sued over Mono. As far as I can see, they're not going to.
I read that before. Back when FSF was urging everyone to avoid LZW compression (used by "compress" and "gif"), because it was patented by Unisys. FSF even introduced their own patent free "gzip" utility, and zlib library to be used in other apllications (unusually for FSF, even proprietary ones).
There were also people harrasing the FSF for that, claiming they were fanatics creating unnecessarty disruptions (compress was the de-facto standard), and refering to low-ranging Unisys people the think had said they were only interested in LZW build into hardware like modems.
Of course, this changed once Unisys out of the blue started demanding royalities for gif creation tools.
The FSF demanding paperwork for contributions to their code is a similar case. Long time before the SCO case.
The sad thing is, when it comes to "intellectual property right", the paranoid tin-foil hats unfortunately tend to be right. And the "happy go lucky" people (like your argument: nothing bad has happened YET, so nothing bad will happen EVER) tend to get burned.