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."
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
Damn, now I have to read the article.
If noone rtfa, then what's the slashdot effect?
Wait a second. Microsoft is willingly employing open source market software? (looks at calendar).. hmm.. it's not early april. It's either armageddon, or old dogs can be taught new tricks!
pm
** "It's not my job to stand between the people talking to me, and the ones listening to me." -- Pego the Jerk
Let's hope this method of reducing spam will work. I have noticed that less spam I receive comes from Hotmail, Yahoo, etc. type e-mails, but hopefully this will help more. I am curious just how much work is involved in publishing these lists, and more importantly, how often are they updated? If they don't get real time or near-real time updates, they aren't going to be very useful.
Microsoft to Deploy SPF for Hotmail Users
So, now that Microsoft already dominates the OS and free e-mail markets, it's trying to get into the sunscreen market as well?
I don't know which is worse, the cure or the disease.
"Have confidence that mail that SAYS it's coming from your bank, your credit card company, or the government really is!"
The problem arises though when the phisher/spammer uses a domain which is fairly similar to your bank or credit cards website, for example www.XYZCapitol.com instead of www.XYZCapital.com.
I sig, therefore I was.
Next year MSFT will release SPF15 for those needing additional protection. SPF 30 and 45 to follow for those extremely pale nerds who never go in the sun
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.
The World Wide Web is dying. Soon, we shall have only the Internet.
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.
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.
It's not that I hate Microsoft. However, I am aware of the company's record of adopting standards and then breaking them. Remember 'embrace and extend'? This could be a step forward for us all. It could also be step back.
UNIX/Linux Consulting
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?
That Microsoft is taking part is to their credit. Finally the Internet at large is going to actually try to apply a solution to spam at the source. Although the unsolicited commercial email problem is largely one of perception (as with violent computer games, smoking in public, or 'indecent' radio broadcasting) perhaps the solution will have less of a negative impact on society. One can only hope.
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
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.
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.
SPF support for most open source mail servers can be found at libspf2.
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.
Um. . .isn't that the point of open source?
I think I'll stop here.
Okay, now we can verify that a mail server that says it is someserver.com is really someserver.com. Back when the big problem was open SMTP relays that sure would have been helpful.
But now that the problem is spam zombies on millions of user PCs, how will this put a dent in the problem? Sure they won't be able to connect directly to Hotmail to say they're someserver.com, but it won't stop them from sending spam through their own ISP's mail server. Since the key to spam zombies is having a lot of PCs that send relatively few spams per PC, it will be very difficult for each ISP to track down and stop each zombie.
Will it be SPF 15 or SPF 30?
But they were registered using GoDaddy, with Hostway nameservers. For this to really get off the ground, the regular hosting companies have to support it as well. The only registrar that offers spf is (that I'm aware of) PairNIC
.
The person that wrote "RTFA" is trying to help you in a more profound way. They are trying to teach to learn to read before asking, something that will make you look like less of an idiot (which you presently look like).
Give the man a fish, and you feed him for a day. Teach the man to fish, and you feed him for a lifetime.
I am unconvinced this scheme will make much of a difference in the spam epidemic.
If anything, the SPF idea primarily favors the big ISPs and consolidated mail services. Microsoft and others aren't doing the industry a favor at all by adopting this standard. It clearly benefits them more than it does small and medium-sized Internet hosts. I am under the impression that for any Internet operation that doesn't control all the inbound and outbound mail for domains they manage will have a much higher administrative burden than the big guys. So this scheme makes sense for large ISPs and costs more time and money for smaller ones.
And ultimately, it would only stop spam if every system on the planet adopted it. Otherwise a spammer will simply operate from a host that isn't SPF-compliant. Until the lion's share of systems adopt SPF, no ISP can afford to arbitrarily reject non-compliant systems.
This scheme seems to heavily favor the "all-in-one" Internet companies, who manage both sending and receiving. If you're having one company manage your domain and using a local ISP for SMTP, then you run into problems. As an owner of a hosting company, if this scheme were adopted, I'd probably get several phone calls a day from customers freaking out that their mail bounced, and even if I had an automated system where they could specify authorized smtp hosts, I'd still have to waste a bunch of time explaining to them that if they configure their local client to be "from" their domain, and they change ISPs, they need to update these records as well.
Ultimately, this is bad. It makes the largest ISPs, who can afford to offer SMTP and all other services, easier to work with, and the smaller guys have more of an administrative overhead to keep up with DNS management.
They've fiddled with HTTP also. ISTR some tricks IE did with IIS to keep persistent connections so that page loads would be quicker.
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*
This does not work if you are a minor player. Microsoft is a minor player in e-mail servers. This is also the reason why Microsoft wants to adopt SPF instead of creating something themselves.
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.
From the article: Messages that fail the check will not be rejected, but will be further scrutinized and filtered
autopr0n is like, down and stuff.
Besides, my understanding of SPF is that it doesn't use anything in the email header at all, only what's in the envelope.
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
I use a forwarding address from my alma-mater as my main personal email address (me@alumni.XXX.edu). They offer a webmail interface, but it sucks eggs. So I subscribe to Yahoo Mail Plus which allows me to send mail "from" any of my accounts (they verify the account before letting me do this), and I can also consolidate several accounts there in one nice interface. When I send email from Yahoo "from" my alumni.XXX.edu address, it comes from Yahoo's outgoing server, and the SPF record from alumni.XXX.edu wouldn't match (if it's there at all).
Is there any mechanism in SPF (or Sender ID) for this email setup?
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 but it appears to need repeating.)
SPF support for most open source mail servers can be found at libspf2.
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
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.
SPF support for most open source mail servers can be found at libspf2.