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."
PGP/GPG? (Score:1, Interesting)
Comment removed (Score:5, Interesting)
Any Windows DNS folk reading this... (Score:3, Interesting)
Easy? (Score:4, Interesting)
Only if you can edit your own DNS records, most management tools only allow modification of A, MX, and CNAME records. For this to really take off the tools need to add support for TXT records.
MSN Broke My Email (Score:5, Interesting)
I responded that I don't use Outlook Express, I use Outlook 2000 and it will only pull Email from pop or imap servers. Their response, upgrade to Outlook 2002 (or above) or just use the hotmail interface. Of course using hotmail means no more hot syncing to my palm and I have to start manually sifting through spam again (my filter I use is an Outlook plug in)
I had been thinking about changing my ISP but now I don't even have a choice.
What ticks me off most is there was no advance notice of these changes- and it took multiple emails to MSN support to find out what was really going on.
Re:PGP/GPG? (Score:2, Interesting)
Bulkmailers will have to encrypt every mail with the public key of the recipient. Considering that the average number of mails in a batch is usually >> 50,000, the amount of time needed is non-trivial.
Apart from that, the bulkmailer will also have to retrieve and store the public key of each single recipient.
I guess it's time to do some research (Score:4, Interesting)
I guess this change means that hotmail users won't be able to receive mail from me unless I read up on SPF and figure out how to get the appropriate configurations into my bargain basement DNS and hosting configs. I hope this doesn't require any administrative privliges since I don't run my own DNS or mail servers for my domains. You can't do that sort of thing for less than $20/month.
Yay, no more hotmail forgery bounces (Score:3, Interesting)
Now if only our anti-spam group would add SPF records. They're deep in the Redmond camp, so the phrase "Microsoft is doing it" should convince them.
Re:Curious (Score:2, Interesting)
Based on the article, it seems like it would... and that's no beef with Microsoft, it's a beef with the filtering systems.
Re:Making sure I see my role in this... (Score:5, Interesting)
Yeah, I was wondering about this too--- particularly how this is going to work with things like universities. Where I just graduated from, you're only allowed to use their SMTP server if you are either on campus, use the VPN, or are using authentication over SSL from wherever. For everyone off campus, you are expected to use your ISP's SMTP server.... and often, you'd have to anyway, with ISP's blocking outgoing port 25 these days. So how then would a university, for example, implement SPF with people using whatever.edu 'From' addresses, but going through thousands of different ISP-owned SMTP servers?
Surely there's a better solution than to have people change their 'From' address based on who's providing their internet connection at that moment (a real challenge for wireless hotspot users.....), and just keep the Reply-To header constant.
Maybe I understand this wrong-- just wondering how it's all going to work.
Re:Making sure I see my role in this... (Score:3, Interesting)
This will be ticky for some family members that I provide (inbound) forwarding service for. In fact, I wonder how this will work for pobox.com forwarding accounts? Will they need to provide outbound SMTP service as well?
How about all the folks that use forwarding addresses like @alumni.myschool.edu? Or @computer.org?
It IS bad, because... (Score:1, Interesting)
Re:SPF version? (Score:4, Interesting)
Re:Hey, Microsoft willingly employs HTTP as well! (Score:5, Interesting)
Re:PGP/GPG? (Score:3, Interesting)
I think that using PGP would be a better system, but I don't think it will ever actually happen...too difficult to implement.
Except PGP would mean you have to accept the complete message, then check the signature (and cache a signature for every from address).
SPF does it a lot sooner, from the FROM command, so you're not wasting that much bandwidth. Also there's less caching as it's one record *per domain*
Embrase, Extend, Modify, ... PROFIT! (Score:2, Interesting)
1. Embrace
2. Extend
3.
4. Profit!!
This is the same company that puts wierd ascii shit in my pine terminal when the email comes from an outlook client. They will fuck with this standard (as they did with OpenGL, Networking stacks, Internet Browsers
Not the ultimate solution (Score:2, Interesting)
What we need is ONE protocol for sending and receiving mail. Let's call it UMP, Universal Mail Protocol. Each domain has one (or several) UMP servers, and a DNS record for looking up the IP number of that server.
When sending email, your domain's UMP server makes a DNS lookup on the recipient's domain and contacts that server. The receiving server looks up your domain's UMP IP number (based on the From-address) and compares it to the machine it's connected to. If they match, the receiver can be sure that it's really sent by the sender.
This would make setup very convenient for the end user!
The only thing to be filled in is: a) email address, b) password.
There's only one server to deal with, which is resolved from the email address.
Of course, this is hard to implement because of lack of backward compatibility, but I think it's worth it.
Just my two bits. Flame on!
Re:Curious (Score:2, Interesting)
In my experience administering a mail server for a group of non-propellerheads, the biggest obstacle to setting up secure email is getting your users set up for it. Tell users that they have to sign in via secure SMTP, on a different port number, under the 'advanced' options in Outlook (I'm not sure if Outlook Express even supports it), and they will start crying and complaining that their email is broken. It's a shame, too, because secure user authentication across the board would take a decent bite out of spam, and god knows it would stop a lot of viruses.
ok yeah, but it only fixes one part of the problem (Score:1, Interesting)
Someone needs to make a new "secure" SMTP protocol... We can't use this public/broken one and keep adding on to it when there are so many other problems...
SPF should be used with a PGP public key database which can be queried by SMTP along with ordb.org and the usual access lists.
OK, so am I screwed now? sort of? (Score:3, Interesting)
lets say one is:
example.com
I currently use Eudora to send email from my primary ISP (earthlink) , but if I want the mail to "appear" as though it is coming from
me@example.com
all I have to do is create a "personality" in Eudora. I use Earthlink's smtp and the only thing I see in the headers is this:
X-Sender: me@example.com (Unverified)
Date: Fri, 23 Jul 2004 12:08:28 -0500
To: user@earthlink.net
From: Microcars (me@example.com)
Subject: test
there is just this (Unverified) line in the X-Sender line, does this mean I will no longer be able to use this function of Eudora?
I can set up POP mail accounts for these domains, but I have to use the WEBMAIL feature of my domain's host because Earthlink blocks port 25 and will not allow me to use another SMTP server (can't use .Mac at home either because of this)
Re:Curious (Score:1, Interesting)
RTFA. This is 'embrace, extend and submit to IETF':
Re:gmail uses SPF (Score:3, Interesting)
r2d2$ host -t txt aol.com
aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
r2d2$
r2d2$ host -t txt hotmail.com
r2d2$
Looks like hotmail needs to practice what they preach.
Re:This is not a solution. (Score:2, Interesting)
Re:Curious (Score:3, Interesting)
I know that at certain universities have blocked the residential networks from using other outgoing mail servers to attempt to stop exploited machines from spamming the rest of the world.
While this is very thoughtful of them it it impossible to accurately use a non university email address. This could cause issues with verifications such as this one.
Re:Curious (Score:3, Interesting)
The reference implementation of the SPF validator includes code to validate using Microsoft CallerID records as well. That means that the XML parser needs to be present on the server.
Port 25 blocked (Score:3, Interesting)
problems with SPF (Score:2, Interesting)
No proof that technology (not legislation) works. (Score:3, Interesting)
First off, it hasn't happened yet. Nothing has been proven to work here, since they haven't actually done anything yet.
Second, SPF doesn't stop spam in the long run. SPF does not even address the problem of spam per se -- it addresses email forgery, and that not very well. In the unlikely event that every email system everywhere implemented SPF restrictions, spammers would still be able to send spam. They simply would not be able to send it under forged addresses in domains that publish restrictive SPF records. They could still send forged spam under domains that cannot (for their own reasons) use highly restrictive SPF, or they could send spam under their own domains.
(Yes, spammers have their own domains. Usually lots of them -- domain registrars' "bulk register" systems allow them to get LOTS of them easily. The registrars get their money, so most of them don't care that the domains are being used for spamming and the contact information is bogus.)
SPF is a case of "solving the wrong problem". The patient has a broken arm, but the quack doctor does not know how to set bones so he gives the patient an aspirin. But the patient's problem is not basically that he is in pain, but that his arm is broken -- the quack is solving the wrong problem.
The Internet's email system basically does not have a forgery problem. People who need to send each other forgery-proof email are already able to do this using systems like PGP. The email system does, however, have a spam problem. Though a good deal of spam is forged, the spam problem goes deeper than forgery. If SPF is widely deployed, spammers will just work around it ... just as they worked around the closing of SMTP open relays by deploying zombie viruses.
The spam problem is today one of ISP accountability, not email forgery. Spammers do their thing, and when people come around to complain, spam-friendly ISPs shine them on. No joke -- take a look around the Spamhaus Project [spamhaus.org], where professional researchers have tracked down the ISPs that do the most to help spammers.
SPF isn't the solution to spam. SPF isn't even the solution to forgery. But it makes nice headlines. People who want to look busy, and look like they are Doing Something to solve a nasty problem, sometimes don't care if the Something they're Doing is actually effective at all.
(Besides, honestly, why would you expect a company which itself sends spam for hire to actually try to stop spam? Microsoft bCentral operates some legitimate mailing lists, but it also allows its list operators to send unsolicited "opt-out" spam. This [google.com] is an archive of reported spam sent using bCentral facilities.)
Re:Curious (Score:3, Interesting)
Re:Making sure I see my role in this... (Score:3, Interesting)
The real distinction is this:
The point of the new port is to allow ISPs to block their dialup customer's outbound port 25 traffic, without preventing legitimate use. Spammers directly connect to port 25 to deliver mail, ISPs block it. Now legitimate users can connect to other ISP's mailservers through this new port. Spammers can't use it because it requires authentication.
SSL has nothing to do with it, except that certain (plain-text) SASL methods are typically not allowed unless SSL encryption has been activated. You enable SSL on a connection via the STARTTLS command, not by connecting to a different port.
I had problems with SPF (Score:3, Interesting)
Since my spam filters are working pretty well, I concluded it was better to live without SPF and let the spam filters deal with the extra junk than to lose mail because of SPF's limitations.