Slashdot Log In
Microsoft to Deploy SPF for Hotmail Users
Posted by
michael
on Fri Jul 23, 2004 11:41 AM
from the ever-so-slightly-less-spam dept.
from the ever-so-slightly-less-spam dept.
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."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Making sure I see my role in this... (Score:5, Interesting)
I maintain a few domains, such as a Sq7.org [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
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
Parent
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.
Parent
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.
Parent
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?
No posts =( (Score:4, Funny)
I'm confused.. maybe I've had too much free beer (Score:5, Funny)
pm
Re:I'm confused.. maybe I've had too much free bee (Score:4, Insightful)
Parent
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.)
Parent
Re:Hey, Microsoft willingly employs HTTP as well! (Score:3)
Yes they do.
You're thinking of HTML, not HTTP which are two different things.
Re:Hey, Microsoft willingly employs HTTP as well! (Score:5, Interesting)
Parent
Great (Score:4, Insightful)
Misinterpreted headline (Score:5, Funny)
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.
Re: Misinterpreted headline (Score:5, Funny)
Microsoft is just trying to protect its empire from the Sun.
Parent
False Sense of Security (Score:4, Insightful)
"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.
Re:False Sense of Security (Score:3, Insightful)
SPF version? (Score:5, Funny)
Re:SPF version? (Score:5, Funny)
(sorry, couldn't help myself)
Parent
Re:SPF version? (Score:4, Interesting)
Parent
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.
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.
Parent
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.
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: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.
Proof that technology (not legislation) works. (Score:5, Insightful)
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.
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.
This is nice (Score:3, Insightful)
The SMTP protocol have sucked for ages, and we applaud any action taken to improve it.
Solves the 1998 spam problem? (Score:4, Insightful)
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.
Yes, but (Score:3, Funny)
I want to use this on my 30+ domains... (Score:4, Informative)
.
How will this stop spamming? (Score:5, Insightful)
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.
This is not a solution. (Score:5, Informative)
no need to panic (Score:4, Informative)
gmail uses SPF (Score:4, Informative)
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: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.
Parent
Re:PGP/GPG? (Score:5, Informative)
Parent
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*
Re:Curious (Score:5, Insightful)
Parent
Re:Curious (Score:3, Insightful)
One way Microsoft could push this is if they implement it in Outlook, which has a monopoly where desktop e-mail clients are
Re:Curious (Score:4, Insightful)
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.
Parent
Re:Curious (Score:5, Informative)
Parent
Re:Curious (Score:5, Insightful)
Besides, my understanding of SPF is that it doesn't use anything in the email header at all, only what's in the envelope.
Parent
Re:Curious (Score:3, Insightful)
What XML? I don't see any XML in the spf1 records.
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.
Parent
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.
Parent
Re:"enforcing" (Score:3, Informative)
Re:"enforcing" (Score:4, Insightful)
Give the man a fish, and you feed him for a day. Teach the man to fish, and you feed him for a lifetime.
Parent