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:Good they've merged. Why XML ?

[Anonymous Coward]

not only that but xml will slow down the dns lookup since the answer will exceed the udp limit and will have to switch over to tcp.

Re:SPF 30

[Pxtl]

Cute. Still, I do wonder why they even advertise this as "caller ID" - after all, everyone knows caller id can be spoofed. Really, the existing e-mail header is the same as caller ID. In theory it says who's calling, but anyone dedicated can get around it.

Why don't they just call it like it is? A secure substitute for the "source" field of the e-mail header.

Lets hope they ditch the patent then.

[patthoyts]

having looked into doing an implementation of CallerID to add to an SPF parser -- I have come away with crossed eyes trying to work out if I'm allowed to release a BSD licensed implementation of this. I think maybe I can -- I'm pretty sure I can't release a GPL implementation though.

Damn, now where did I put that lawyer....

Re:Boycott of Microsoft's Caller ID for E-mail

[Rayban]

I heartily agree! It's good to see them cooperating, but I hope that the final license has a royalty-free patent grant with no attribution clauses.

If the two camps agree, this will speed up adoption of SPF records enormously.

Spam solution already exists

[Rashkae]

Spam would very quickly cease being a problem if mail clients were configured to start using PGP (GPG) keys and signatures by default. There is no need to re-invent or even change the e-mail RFC's.

Very simply, people can choose whether they want to receive unsigned e-mail, or accept sinatures from unkown keys. We'll eventually start building a web of turst (mistrust), such as, being able to automatically accept a key signed by some people or orgs, and similarly, blacklisting keys.

I could very easily, for example, instruct unknown senders (people who aren't in my contact list yet) to download my public key from a specified location to encryp a message that would bypass my filtes. Only a person who followed the instructions would be able to send me an unsolicited message.

Re:Spam solution already exists

[Rashkae]

Well, I have to disagree with your proposal. I'm one of those stubborn bastards who sends mail through my own e-mail server.

1) I really hate webmail.

2) As the administrator for our small network, I prefer to have direct access to the e-mail server logs for security and verification purposes.

3)Your suggestion would still not solve the spam problem.

As annoying as the constant Viagra and porn ads are, not to mention offensive to some people, 3 years from now, those will be pleasant memories compared to what's going to happen once MS and friends convice the powers that be (FCC et al) that the real problem is porn and scams, and therefore the solution is to create a mechanism for legit businesses to send legit messages. I forget the statistics, but I remember a post somewhere about how many spams we'll be getting per day if every business in the US sent 1 unsolicted message per year.... it was frigthening.

((Besides, the Viagra ads are starting to get artful and entertaining.))

dynamic dns users

[tacocat]

How will this effect dynamic DNS users who send email? I'm not talking about some rogue spammer, but the people who have legitimate servers running on real IP addresses with domain names that are managed by the likes of dyndns.org

In the past, these DHCP hosted addresses have been under a lot of grief with people erroneously RBLing them simply because they are DHCP (like it ever really expires!!!) managed IP addresses.

Much of the workaround for this has been to RELAY all the email up to the ISP for delivery from a non DHCP hosted IP address. But some people block these because they show evidence of being relayed by anyone and hence must be evil.

So what will have to do in order to get my mail server considered acceptable for sending email under this SPF/CallerID scheme?

I'm also really curious to see how this can be a good thing at the same time that it involved Microsoft, but I'm trying to keep an open mind on this one...

Except for Microsoft's embraced and extended email

[kyz]

where all you get is (if you're lucky) a text version of the email message, then a WINMAIL.DAT uuencoded or MIMEd attachment, which contains all the useful data in a proprietary binary format.

Rather than simply create compliant MIME mails, Microsoft uses this secret format to say "yeah, we'll try and send email, but if you really want to communicate with companies that use Exchange Mail Server, you need to buy a copy of Exchange Mail Server".

And this is different from the GPL???

[Anonymous Coward]

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.

And this differs from the GPL how?

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

Touché Microsoft methinks

What if.

[man_ls]

What if, say, businesses started showing up promising "unrestricted email" to get around SPF.

They set their SPF to everyone/everyone...or something.

Then it's an open relay with an SPF signature that matches.

and we're back to square 1.

Re:What if.

[taustin]

More likely is that spammers will take the doznes, or hundreds of domain names they register at a time now, and that they run their own DNS for now, and simply automate adding SPF records for, based on their current IP address.

No "email for this domain is allowed to come from these machines" program that is under control of the domain owner has any hope of reducing spam, because spammers will just use it, and keep cycling through disposable domain names at $5-10 each. Only .mail solves that, and that's at the expense of giving someone else control over some of your email settings (and paying them $2000 for the privilige, per domain).

In the short term, if whitelisting based on SPF becomes popular, it will increase the amount of spam coming through. In the long run, it will have zero effect.

AOL and MS say: publish SPF records

[wayne]

AOL just added a webpage saying that you should publish SPF records if you want to be whitelisted with AOL.

The MicroSoft Caller-ID/SPF merger proposals say that SPF records will be honored, so you can publish them without fear of losing support.

So, go ahead and publish SPF records.

MicroSoft supporting SPF records is a really smart move. Last week, I posted results of a survey of 1.3 million email domain names to the IETF MARID mailing list. Now that I'm back from the MARID meeting, I just finished a survey of Caller-ID records. There appears to be about a factor of 500-1000 more domains that have published SPF exclusively than Caller-ID exclusively and only a tiny fraction of the 1.3 million domains have published Caller-ID records. In short, MicroSoft isn't changing to support SPF records because they are better (I think they are), but because it is an acknowledgement that MicroSoft's Caller-ID hasn't caught on.

Meng Weng Wong (the SPF author) and MicroSoft are still discussing how exactly this merger will work on. I personally don't see any reason to support XML right away. MicroSoft has not come out with a single concrete extention that can't be done with SPF already.

I also think that there are alternatives to the complex Caller-ID algorithm and that doesn't require every Ezmlm and other mailing lists to upgrade their software. From the research that I've done (and yes, this is something I have really researched), there appears to be far more mailing lists broken by MS's Caller-ID system than email forwarders broken by SPF.

(I'm the author of libspf-alt and the maintainer of the trusted-forwarder global whitelist. So, now you know why I have researched this stuff so much.)