Microsoft to Deploy SPF for Hotmail Users 562
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."
No. RTFA (Score:2, Informative)
A failed PRA check will be a "factor" that Microsoft's SmartFilter technology will use to determine whether a given message is spam, according to George Webb
Re:Curious (Score:2, Informative)
*And* requiring a totally useless XML format, so that every SPF-capable MTA has to incorporate an XML parser.
(feeling like one of them, strangely...
Re:PGP/GPG? (Score:5, Informative)
nice concept but not as practical in all scenarios (Score:5, Informative)
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... (Score:5, Informative)
So you could add your server + your ISP's servers, so your fallback would still be within your SPF record
Re:PGP/GPG? (Score:1, Informative)
With SPF, you can tell that a mail comes from a server which isn't supposed to send it, if SPF records are present and the mail was sent through a server which doesn't match.
With PGP, you can tell that a mail comes from the person who owns the key, if a PGP signature is present and checks out ok. You cannot tell if a mail comes from the person who owns the mail address if no PGP signature is present. PGP would have to have a very high market penetration to be useful as an anti-spam indicator.
Re:What is the difference between SenderID and SPF (Score:5, Informative)
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:MSN Broke My Email (Score:3, Informative)
Customer or user? Customers pay for a service and expect a level of support for their dollar. Most pople who have Hotmail acounts are just users, who pay nothing and should not expect anything back.
Re:Curious (Score:5, Informative)
Re:Easy? (Score:4, Informative)
This of course means that my outgoing mail will probably get spam filtered in the near future unless this changes.
Re:"enforcing" (Score:3, Informative)
I want to use this on my 30+ domains... (Score:4, Informative)
.
Re:Hey, Microsoft willingly employs HTTP as well! (Score:2, Informative)
This is not a solution. (Score:5, Informative)
no need to panic (Score:4, Informative)
gmail uses SPF (Score:4, Informative)
Re:I'm confused.. maybe I've had too much free bee (Score:4, Informative)
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.
(Yes, I posted this once [slashdot.org] but it appears to need repeating.)
Missing the point (Score:5, Informative)
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:This is not a solution. (Score:3, Informative)
No, it's just not a solution for everyone.
If you don't publish SPF records, nothing changes. Mailservers are unlikely to reject mail from domains that don't have SPF records for a long time, maybe ever, depending on how broadly used it is.
If you do publish SPF records, you can indicate whether or not your the record describes all hosts that can send mail for your domain. Adding ~all means:
SPF FAQ [pobox.com]
Re:Curious (Score:1, Informative)
Can SPF be implemented in Outlook, or ANY mail client? I ask because SPF basically seems to ask "Is the IP address that sent me this message an IP address that is authorized to send mail for the domain it claims to be from?" This is easy to check at the mail server when it is received--you just look at the IP address that is connected to the server, get the SPF record for the "FROM" command, and see if the IP address is authorized.
But if you try to implement this at the client level, the message has already been received by possibly a firewall, forwarded to an internal mail server (or through a couple), and the email client has to figure out what address really sent it. Parsing "received" headers is difficult because every MTA seems to have its own way of writing received lines, plus received lines are easily forged.
So how could a mail client implement SPF? It seems like it's something that has to be implemented at the server level unless the Received: lines are truly standardized.
Re:Making sure I see my role in this... (Score:2, Informative)
you'd have to anyway, with ISP's blocking outgoing port 25 these days
If they're requiring authentication over SSL before you can relay (which is a good choice on their part), they may also have SMTPS (port 465) open, which would sidestep the ISP firewall problem.
Re:Curious (Score:4, Informative)
The checking of Caller-ID records in the perl reference implementation has always been optional. I know of only one other SPF implementation that even has Caller-ID support as an option. With the push by Microsoft to use Sender ID (which doesn't use XML) instead of Caller ID (which uses XML), I expect these optional XML checks to be eliminated.
I ran a study of 1.3 million email domains and found only a couple dozen domains that published Caller ID (XML) records, but not SPF records. (Details of this study were posted to the IETF MARID mailing list.) There simply is no good reason to enable these optional Caller ID checks.
Set up your own SPF records (Score:3, Informative)
I did this for my domains in about 5 minutes.
The problem with MS SPF... (Score:2, Informative)
Will these servers be blocked by the rest of the world? At least initially, this seems hardly fair.
So the only problem this poses to spammers is to find a few of those domain names that don't incorporate SPF records, and *tada*, they have a new list of email domains to zombify.
Re:Making sure I see my role in this... (Score:3, Informative)
The big change that might need to be made is to support SMTP Auth over port 587. However, I suspect that they already do this (its part of the SSL/Auth setup). This should just be a matter of changing client configuration to go there. No VPN needed.
RTFA: ipv4:0.0.0.0/32 (Score:1, Informative)
RTFA: you can just add 'ipv4:0.0.0.0/32' and allow the entire internet to send from your domain.
Re:Curious (XML is *out*) (Score:1, Informative)
(sigh) Not informative
Last I looked at the mailing lists, XML is out with regards to MARID. Go read the archives of the IETF's MXCOMP mailing list.
Re:Missing the point (Score:5, Informative)
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.
Re:Making sure I see my role in this... (Score:4, Informative)
First off, unless your desktop machine is running a full SMTP daemon (e.g. sendmail / postfix / exchange / etc.) you're not supposed to be talking to other SMTP servers on port 25. The fact that you've been allowed to do so is laziness on pretty much everyone's part. Client machines should be talking to their SMTP server in an authenticated manner using one of the ports like tcp/465 and the like. Which is not a port that ISPs are blocking.
Secondly, if you want to send e-mail from a particular domain, that domain is perfectly within it's legal rights to say "you must use our authorized outbound mail servers". Which is what happens when they publish SPF-type information. Right now, using the MX records, a domain can specify what machines are authorized to accept incoming mail for that domain. (You wouldn't route mail for domainA.com to domainB.com's mail server and expect it to be delivered, right? Unless domainA's MX record specifically says that domainB.com's mail servers will handle that e-mail.) SPF information is simply the mirror image of the MX record (more or less).
Third, if we allow you to forge our domain on your e-mail and send it willy-nilly from any hotspot or mail server on the planet... well, that means that any spammer or worm can also forge our domain onto their mailings. This is extremely frustrating to a mail admin who has to deal with hundreds and thousands of mis-directed bounces from forged e-mail. The only solution is to stop domain forging from being allowed on the network. At least with SPF-type solutions, it's up to the owner of the domain to choose to publish SPF-type information and how strict they want it to be.
In short, if you want to send e-mail from domainX who publishes SPF information, you will need to abide by the rules that domainX has chosen to publish. Most likely this will require you to either VPN into their network or use an authenticated SMTP session to route mail through their mail server.
If you don't agree with domainX's rules, you are perfectly free to setup your own domain and publish your own SPF records (or not publish any).
Heck, AOL already does SPF on an ad-hoc basis, where you have to register for a whitelist if your domain sends more then a handful of e-mails to their users per some time period. At least with SPF, I can publish a single record for my domains rather then having to register with every Tom, Dick, Harry, and Jane ISP on the planet.
Re:not a solution (Score:3, Informative)
Re:Making sure I see my role in this... (Score:2, Informative)