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

the origional

[millahtime]

Here is the origional

Re:How is this supposed to solve anything?

[Smallpond]

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.

DHCP was NOT developed at Microsoft

[hta]

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.

Re:Similarities

[Void_of_light]

I dont know about where you live but SBC charges almost 10 bucks a month to tell me who is calling.

Re:The real problem is proprietary ownership of th

[_Sprocket_]

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.

From http://www.openbsd.org/lyrics.html:

The IETF community proposed work in this direction in the late 90's, however in 1997 Cisco informed them that they believed some of Cisco's patents covered the proposed IETF VRRP (Virtual Router Redundancy Protocol); on March 20, 1998 they went further and specifically named their HSRP "Hot Standby Router Protocol" patent. Reputedly, they were upset that IETF had not simply adopted the flawed HSRP protocol as the standard solution for this problem. Despite this legal pressure, the IETF community forged ahead and published VRRP as a standard even though there was a patent in the space. Why? There was much deliberation at all levels of the IETF, and unfortunately for all of us the politicians within eventually decided to allow patented technology in standards -- as long as the patented technology is licensed under RAND (Reasonable And Non Discriminatory) terms. As free software programmers, we therefore find ourselves in the position that these RAND standards must not be implemented by us, and we must deviate from the standard. We find all this rather Unreasonable and Discriminatory and we *will* design competing protocols. Some standards organization, eh?

A better suggestion than Caller ID/SPF

[0x0d0a]

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

SPF + Caller ID are merging

[jgardn]

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.

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.lis tb ox.com/200405/0198.html