Microsoft to Deploy SPF for Hotmail Users

wayne writes "In a show of just how much Microsoft wants to put an end to email forgery, Hotmail, MSN and Microsoft.com will start enforcing Sender ID checks by Oct 1. In late May, MicroSoft announced that they would be adopting the Open Source SPF anti-forgery system (with a slight modification to make it Sender ID) and they have been working together with the IETF MARID working group to help create an RFC to define the Sender ID standard. Already tens of thousands of domain owners, such as AOL, Earthlink, and Gmail, have published SPF records, and thousands of systems are already checking SPF records. Publishing SPF records is easy, as is checking SPF records."

Comments

Re:PGP/GPG?

[FooAtWFU]

PGP/GPG are nice, but they have nothing to do with the anti-spamming technology present in SPF. All SPF is, is special data set in your DNS telling you which hosts are allowed to send mail on behalf of your server. That way when your 0wn3d computer sends mail from "hotgirl@hotmail.com", people can tell it's a fake.

nice concept but not as practical in all scenarios

[mabu]

Generally, I like this idea, especially from the perspective of controlling misdirected bounces.

Where it seems to be a problem though (someone correct me if I'm wrong), is in a case where someone, for example is doing web hosting and controls a domain, and the customer wants to configure his e-mail client to send mail "from" the domain through a local ISP. The way SPF works, the authorized hosts from which mail with that domain in the header must be defined in the DNS records. This means that if the hosting company isn't the customer's ISP or mail relay, he needs to keep track of what mail relays the customers use. If a customer changes ISPs and doesn't have the DNS info updated, then their mail may suddenly be rejected by SPF servers?

This seems to be good for ISPs and services like Hotmail and gMail, which endeavor to have exclusive control of incoming and outgoing mail under their domains, but for smaller ISPs or scenarios where one person may be managing the domain, with the customer using a local ISP/mail relay, it seems to be a big pain in the butt.

Re:Making sure I see my role in this...

[YetAnotherDave]

SPF allows you to state a list of servers which are qualified to send.

So you could add your server + your ISP's servers, so your fallback would still be within your SPF record

Re:What is the difference between SenderID and SPF

[wayne]

Okay, all I know is that SPF is a good deal simpler than SenderID and much more popular, due to the simple text format verses the use of XML.

XML was dropped from the Sender ID spec by the IETF last month.

The primary difference between SPF and Sender ID is that Sender ID also has the ablility to check the RFC2822 From: email header in addition to the RFC2821 envelope from value. This is something that most of the people in the SPF community wanted to do all along, but it would require changes in end-user mail systems, such as outlook, to do right. Without the support from MicroSoft, this couldn't really be done.

Re:Curious

[E-Rock]

My understanding is that you should be changing the REPLY-TO not the FROM. Let FROM be where the message is actually from and there's no blocking problem. With the REPLY-TO set, anyone that presses reply goes to your prefered destination.

This is not a solution.

[pavera]

SPF requires that you know every mail server that will ever relay mail for your domain. This is unknowable. I manage 40 domains, people using these domains for email regularly travel to branch offices where they change their outgoing smtp server to whatever server is local to that office... I'm talking about a rotating list of around 1000 smtp servers that have to be on all 40 of these domains... That is the most unmanagable hack I've ever seen. This is not one company I manage small domains for contractors that need to be able to have 1 email address, but that are constantly moving to different physical locations, and using many smtp servers. Furthermore, VPN is not a solution as most of the time they are on heavily firewalled and NATed networks where VPN does not work reliably. Also, I work for a small ISP and many of our users use our outgoing smtp server to relay mail for their work accounts that don't have VPN set up for them. All of this email will now be summarily rejected.... whoever came up with SPF is an idiot, thanks for breaking email, this is the death of it.

Missing the point

[eadz]

A great opt in solution... .. If you don't have SPF records in your DNS, it doesn't mean Hotmail won't accept your mail.

If you DO have SPF record for your domain, and the message wasn't sent from one of the specified IP addresses, then Hotmail may block your message.

But the real kicker is when you recieve a message from someone@hotmail.com. If the IP address used to send the message isn't listed in hotmail's SPF TXT DNS record then you know it's not a message sent from hotmail. And same for Gmail :

dig -t txt gmail.com
gmail.com. 300 IN TXT "v=spf1 a:mproxy.gmail.com a:rproxy.gmail.com -all"

Which means that the only servers authorized to send mail from @gmail.com are mproxy and rproxy.gmail.com

Re:Missing the point

[Otto]

OK- so if I have my own domain:
example.com
and I choose NOT to have an SPF record for that domain, I should be able to SEND emails out as per my post above and they "should" go through and not get rejected?
The only reason I would WANT to publish an SPF would be to PREVENT a spammer from using example.com as a bogus FROM address?

Pretty much, yes. Although it's slightly more complicated than that.

If you don't publish an SPF record for your domain, then the receiving machine will have to fall back on whatever the default is. The default, however, is not defined. It can be accept the mail, reject the mail, accept the mail but flag it as possibly forged, accept the mail and add a "no SPF" weighing to whatever anti-spam algorithim it uses, etc. Basically, it depends on who you send it to.

Since there's not a heck of a lot of places using SPF yet, any likely defaults currently are to accept the mail. Once SPF is widely implemented, a lot of those might start flagging it as a possible forgery or maybe even simply rejecting it altogether. But that may never occur, basically.

The advantage to SPF is mainly when the sender has SPF records published and the receiver is reading and acting on them. In that event, it'll work all the way through. But you don't really see a lot of spam prevention benefit until SPF is very widely adopted and the defaults start to become something other than "accept it if there is no SPF record".

But you're right in that publishing a SPF record has absolutely no negative consequences and can only prevent spammers from forging your domain name to receivers using SPF records.