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

Comments

Why XML ?

[Space cowboy]

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 :-) tag with virtually the same semantics as an MX tag (obviously a different payload, though, in the same way as MS propose) ?

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.

Re:Why XML ?

[nacturation]

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.

XML is great for extending *structured* data. I think you're right as far as DNS goes though... after all, coding for backwards compatibility in the current DNS format is as trivial as setting the server to ignore any unrecognized tags. Hey, just like XML!

How does this benefit Microsoft's bottom line?

[JessLeah]

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.

Why?

[burgburgburg]

It's usually obvious how Microsoft will benefit from an action. It isn't here. Other than controlling the direction of the solution in a way that won't surprise them and taking momentum away from others, what is the advantage to Microsoft in proposing their caller id as opposed to going forward with the solutions already out there?

The cynic in me is incapable of imagining that it is technical superiority that drives them.

Re:Why?

[taustin]

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

Re:The real problem is proprietary ownership of th

[hpa]

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

How is this supposed to solve anything?

[KalvinB]

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

Both implementations have problems.

[Anonymous Coward]

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.

More Anti-Microsoft FUD

[Rick and Roll]

All of the posts I see so far are ones complaining about Microsoft having control over it. This is an IETF standard they're proposing. Microsoft has not sued over Mono. As far as I can see, they're not going to.

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.

Re:More Anti-Microsoft FUD

[taustin]

All of the posts I see so far are ones complaining about Microsoft having control over it

Here's a compalint that has nothing to do with who proposes what:

This suffers from the same flaw as SPF. The records in question are controlled by the spammer, so it will do nothing to reduce spam. If anything, it will increase it. Spammers already cycle through dozens, even hundreds of domain names per month. All they need to do is add the necessary SPF/Caller ID domain records - which will be completely automated in their automated "sign up for hundreds of domain names at a time" scripting, and their spam will get whitelisted by anybody who swallows what is being spoon fed them by Microsoft or the people behind SPF.

Re:More Anti-Microsoft FUD

[pyrotic]

Usually DNS records take 24 hours for changes to propogate across the whole of the net. Some blacklists pickup spammers in the same kind of timeframe. So as a spammer, you'll have a very small window of opportunity from the moment your DNS records are valid to the moment you're on a distributed blacklist.

A lot of spam we see comes at work from people with no reverse IP address. I would dearly love to block all mail from sources without a proper DNS setup, but there are too many legit correspondents out there.

Greylisting is one solution we're looking at, where you give a temporary failure to incoming mail. Wait for a while, see if someone is still trying to send you that mail. If they are, chances are at least they're not a zombie ADSL PC.

If only the original authors of SMTP could have seen the mess we're in now.

Re:More Anti-Microsoft FUD

[pavon]

You misunderstand the purpose of SPF. It is not much of a solution in and of itself. It only garentees that email came from the domain it claims. The solitary benifits of this are small like you claim. However, once you have a garenteed method of tracking email back to a domain, you suddenly create the possibility for all sorts of measures.

Suppose spammers did set up SPF. If they follow the spam laws it is trivial to filter all their mail at the server. If they aren't, it is trivial to prove that they are breaking the law, and approach things that way. It is also now safe to blacklist them because you have proof that the incriminating spam came from them and wasn't forged. No more joe-jobs.

SPF lays the groundwork to make it useless to spam from dedicated servers, which is half of the total solution. The other half is dealing with hijacked machines. In my opinion the only solution here is to is get ISP's to start taking responcibility for firewalling hijacked machines from the network. When you sign up for a connection you either get their "home" line which they run a firewall on, and comes with mail etc. Or you get a "business" line that is static IP and is not allowed to use thier mail servers, so you are completely free and completely responsible for what you do with that IP.

Re:More Anti-Microsoft FUD

[taustin]

Suppose spammers did set up SPF.

Suppose spammers set up and SPF record for 0.0.0.0/0.

If they follow the spam laws it is trivial to filter all their mail at the server. If they aren't, it is trivial to prove that they are breaking the law

Suppose the spammer is using a DCHP IP address. Suppose the spammer is sending their spam through the corporate mail server at a major ISP (who let them, in a pink contract). Suppose the spammer is using trojaned machines in Europe and China, and other parts of the world where US law doesn't apply.

You've got nothing new. All these issues have been dealt with by spammers in the past, quite successfully.

SPF will have zero affect on the amount of spam being sent, and will most likely increase the amount being received, until mail admins figure it out.

Re:More Anti-Microsoft FUD

[taustin]

Usually DNS records take 24 hours for changes to propogate across the whole of the net.

Unless the spammer sets the TTL to, say, five minutes. You can override that, but there are hazards to doing so.

So as a spammer, you'll have a very small window of opportunity from the moment your DNS records are valid to the moment you're on a distributed blacklist.

About the same window of opportunity that they have with disposable dial-up accounts, which have been a standard spammer trick for years. At worst, they'll just register a hundred new domain names at a time instead of 50. Won't slow 'em down.

A lot of spam we see comes at work from people with no reverse IP address.

That is a valid and useful thing to block or filter on. I currently block any IP that sends me spam that has no rDNS.

Graylisting is at least more likely to stop spam than legitimate email, but it has its hazards, too. Not all mail servers are configured correctly.

If only the original authors of SMTP could have seen the mess we're in now.

The original authors of STMP would view trying to block spam as network damage, and built a protocol robust enough to handle it. They couldn't imagine what email has become.

Just because M$ profits does not mean

[Archfeld]

every one else can't as well. I 'trust' an entity will an obvious reason for their behavior, ie profit, much more than I trust a so called altruistic entity, fanatics are SCARY.

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

XML good. For some things.

[MrChuck]

the BIND format is inherently non-XML

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.

Re:Why not digital signature

[Openstandards.net]

And what Certificate Authorities (CA) will your email server consider acceptable? The problem is that certificates cost hundreds of dollars a year because they are commercially controlled by a few CAs (e.g., Verisign). Why should people have to shell out $150/yr just to run an email server? It's bad enough to have to do it in order to use SSL on websites without the user getting a prompt "warning them".

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.

Would forwarding companies please get in touch

[mengwong]

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

Better, but still not enough

[14erCleaner]

This is a step in the right direction (and maybe we should be practical and take what we can get), but...

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.

Re:Better, but still not enough

[MavEtJu]

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.

What the problem is about is more that SMTP doesn't allow some kind of verification of the source. With these proposals the source verification is added.

In your first case, that's a matter of host security, not SMTP security. In your second case, that's just plain evil of them but nothing SMTP can do about it.

Edwin

Re:Why not digital signature

[MavEtJu]

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