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."
Messages that fail the check will not be rejected, but will be further scrutinized and filtered, said Craig Spiezle
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
They'll tell Microsoft burried SPF by requiring post-DATA checks on messages (parsing of RFC 2822 headers), instead of pre-DATA fast MAIL FROM parsing.
:-)
*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...
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.
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.
SPF allows you to state a list of servers which are qualified to send.
So you could add your server + your ISP's servers, so your fallback would still be within your SPF record
PGP solves a different problem.
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.
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.
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.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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.
And currently most free dynamic DNS services do not support it.
This of course means that my outgoing mail will probably get spam filtered in the near future unless this changes.
It's a new open standard that forms part of the way you send mail from now on. It is a very worthwhile method of cutting down on SPAM that spoofs it's origin. If you (or more likely your ISP) don't want to conform to the standard, no one is stopping you from sending eMail. But you just have to accept that there is a much higher chance of it being filtered by a spam filter, no matter who you send it to.
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
.
You're confusing HTTP with HTML.
Dissolve... Resolve... Evolve...
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.
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
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.
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 ...
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.
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.
It's amazingly easy. There's a little wizard here you can use to set up your DNS.
I did this for my domains in about 5 minutes.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Does anyone see the challenge of getting EVERYONE in the world to adopt SPF tactics to stop spam? There will always be back-water companies who have an SMTP server who WON'T have SPF initiated.
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.
Computers are useless. They can only give answers. --Pablo Picasso
The SSL connection with authentication should not be made over port 25. Port 25 is for standard (non-SSL, non-Auth) connections. While it might accept the other connections, it is not the preferred port for this.
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.
SPF requires that you know every mail server that will ever relay mail for your domain.
RTFA: you can just add 'ipv4:0.0.0.0/32' and allow the entire internet to send from your domain.
*And* requiring a totally useless XML format, so that every SPF-capable MTA has to incorporate an XML parser.
(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.
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?
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.
Wolde you bothe eate your cake, and have your cake?
Well, actually they would need to spoof thier IP address over TCP (as opposed to UDP) This would prove to be rather more difficult than the current spam sending regime.
----- Question authority, but not ours. Hate the man, but we're not him.
Actually the preferred way is to connect to port 25 and issue a STARTTLS command. The older practice of assigning two ports for every protocol, the second of which is to be used with SSL, does not scale.