SPF To Be Integrated With MS 'Caller ID' System

An anonymous reader submits "CNET's news.com is reporting 'An ongoing effort to consolidate antispam authentication schemes took a big step forward with the merging of Sender Policy Framework (SPF) and Microsoft's Caller ID for E-mail.' This is potentially good news." For more background, here are three previous mentions of Microsoft's proposed Caller ID-style system.

Comments

Re:Why not XML?

[lpontiac]

XML is not a format. It's a metaformat.

Re:Good they've merged. Why XML ?

[thogard]

Cracker will love the xml format. It turns out that the record size will exceed the UDP packet size for DNS records so they get upsized to use TCP packets.

The thing is how many people allow TCP packets on port 53 on their firewall? There is no reason execpt to talk to your second-dns records. All other cases should be turned off but this requires that it be turned on.

breaks forwarding

[close_wait]

I dislike SPF because it breaks forwarding. There is a "workaround" but that's required on every MTA in the world that allows forwarding, and is intensely ugly - it requires adding a bunch of garbage to the sender address, and also requires the MTA to main a cache of forwarded addresses so that bounces can be passed back down the chain.

The problem is this. Suppose AOL start adding SPF records to their DNS, saying effectively 'only the following IP addresses are authorized to send @aol.com emails. Suppose also that Hotmail start rejecting emails from SPF domains where the IP addresses don't match. Now suppose that joe@small.biz is going to be away from the office for a couple of weeks, so he gets the small.biz mail server to forward his emails to his hotmail account. At this point anyone from AOL who emails him will find the emails bouncing (although if they're from AOL, this may not be such a bad thing...)

Re:Sounds like a truly awful idea

[FattMattP]

But wait -- SPF doesn't block spam!

Correct. It's not meant to. SPF's goal is to prevent domain name forgery. Blocking spam, if it does that, is a side effect. Authenticating the sender is the primary goal.

It just blocks spam where the From: is not right.

No, that's what MS "Caller-ID" does. SPF checks the MAIL FROM in the SMTP transaction. Think of it this way, SPF does its checks on the envelope and caller-id does its checks on the header.

The only potential real benefit, I suspect, would be to make phishing harder.

That's the point.

Re:Good they've merged. Why XML ?

[Allen Zadr]

Actually - nevermind. I found a reason why I can't impliment this technology, ever.

Use of this technology requires submitting to a Microsoft license. This license allows distribution (but not re-distribution), and is not compatible with the GPL. That is to say, no GPL mail server will ever be able to directly impliment checks for this.

From the license (forgive typos, I typed this from the PDF):

2.2. Source Code Distribution You also have a nontransferable, non-sublicenseable, personal, license to distribute or otherwise disclose source code copies of such Licensed Implementation licensed in Section 2.1 only if You (i) prominently display the following notice in all copies of such source code, and (ii) distribute or disclose the source code only under a license agreement that includes the following notice as a term of such license agreement and does not include any other terms that are inconsistent with, or would prohibit, the following notice:

"This source code may incorporate intellectual property owned by Microsoft Corporation. Our porvision of this source code does not include any licenses or any other rights to you under any Microsoft intellectual property. If you would like a license from Microsoft (e.h. rebrand, redistribute), you need to contact Microsoft directly."

That, my friend, is embrace, extend and assimilate. Nothing under strict GPL can impliment this natively. IIRC, SPF (Sender Permitted From) did not have source restrictive terms.