Slashdot Mirror
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."
Why not just use PGP or GPG? I for one, would like to see greater implementation (read: any implementation whatsoever) of these systems in the more common web-based/free email systems such as Yahoo and Hotmail.
The old Lie: Dulce et decorum est Pro patria mori
Ok.. Let me make sure I understand this correctly..
I maintain a few domains, such as a Sq7.org, from which I send e-mail.. I send it from home, from my girlfriends house, from wherever I happen to be.. But I send it by connecting through the sq7.org server, and forwarding mail through there.
The way I understand SPF, I just need to publish that the IP sq7.org runs on is authorized to send Sq7.org's mail, and NOT the IP for my home, office, etc, since I don't send directly from the local computer.
If I did send directly from the local computer, without going through the external server, I'd need to add my local IP to the SQ7.org DNS records.
As it is, though, I'll need to avoid using my ISP's SMTP servers if mine go down, or add them to the domain.
Am I understanding this right?
-Colin
Colin Davis
Is there a easy guide to deploying SPF on Windows 2000's DNS Service? Something that I can give the MCSEs who run our IS team and get their attention would be appreciated.
Go somewhere random
Publishing SPF records is easy, as is checking SPF records."
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.
They are making all kinds of changes lately-- and they are not bothering to send anything to their users. I've been an MSN customer since just after they started up the service. Last week Outlook couldn't pull my email from their pop3 server any more. I sent in a help ticket. The reply I got said it was a problem they were fixing- and gave me instructions to set up Outlook Express to pull web mail from an http server.
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.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
I have a couple of domains registered and pointed at a cheap shared host. I generally send mail using either Mutt over ssh or Mozilla via several different SMTP servers (cablem modem ISP, web host ISP, work SMTP server) and I routinely edit my from address to use whatever userid and whichever of my domains is relevant.
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.
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.
I can't quite get my head around how this affects me, actually... I'm a student at University of Illinois, I use an @uiuc.edu email address. If I live in an apartment off campus, however, I send my outgoing mail to my ISP's smtp server with my uiuc.edu address as the "from" address, because that's where I prefer to get my e-mail. So will this put my e-mail to SPF-enabled receivers under scrutiny? Or am I OK as long as my ISP is legit according to this system?
Based on the article, it seems like it would... and that's no beef with Microsoft, it's a beef with the filtering systems.
it will make it more harder for guys like me to run an SMTP server on their own Linux box from a dynamic IP address. And it will do pretty much nothing to prevent spam.
That's exactly what you're supposed to think
They've fiddled with HTTP also. ISTR some tricks IE did with IIS to keep persistent connections so that page loads would be quicker.
Ah yes, an twist on the old profit algorithm ... ....)
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
What we'd really need is a completely new email system. The system right now is very complicated, both for "tech people" and for end users. We've got POP, SMTP, IMAP, you name it. Sometimes, SMTP requires login, sometimes not. There's a myriad of old protocols and standards out there that needs to be replaced with new technology.
:-)
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!
Sig Nature
If you want your email to be From uiuc (as well as From: uiuc, which is not the same thing), you should use uiuc's SMTP server for outbound mail. They may require you to authenticate (possibly in cleartext, possibly over SMTP/S), or they may require you to VPN to the campus network, so that their mail server sees it as coming from internal (and therefore allowed to send From uiuc).
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.
SPF is good, but what about the ability to forge email from user@localhost, undisclosed.recipients@yourdomain.com, etc). These are security holes large enough in the SMTP protocol to drive a truck through... Most people run on the default Sendmail rulesets. If they can't send but from your domain, they will forge their way though with the broken rulesets and other hacks...
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.
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)
I like microcars
RTFA. This is 'embrace, extend and submit to IETF':
More surprisingly, hotmail does not.
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.
Can I get an eye poke?
Dog House Forum
I think it would be better for the mail to append a header flag along the lines of (SPF=BAD_DOMAIN) rather than summarily reject it. That tag could also be taken into account with SpamAssassin and bump the spam score higher. I am of the opinion that most deleting of email should happen client-side. The only time mail should be deleted server-side, IMO, is if it contains a virus.
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.
100% Crunchier
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.
What about in the situation I have where I have to use my ISP SMTP server to send ALL the mail I wish to send since they disallow access to port 25 for all servers other than their mail server (ie send a person@yahoo.com email through my isp.com SMTP server)? Since I'm tied to this scheme, apart from using a web interface, will SPF work in this situation?
Even the samurai
have teddy bears,
and even the teddy bears
get drunk
After reading this, I'm not sure I want to implement SPF on my domain. I use some features like pre-forwarding with qmail-ldap that will break because of SPF. And not to mention alot of the RFCs that it seems to break
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, 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 is an archive of reported spam sent using bCentral facilities.)
Well, my mail provider deployed SPF quietly and the result was a few months of occasionall dropped mails: mail forwarding from one low-volume but important domain didn't work. When I looked into how that could happen, it seemed like SPF was working the way it was supposed to, it was just that unless the whole world switched to it, this sort of thing was bound to happen.
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.