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."
To me this sounds like a positive step. I'm just wondering what the Microsoft haters will post about it to make it sound like a bad thing...
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.
"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.
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 will never post my private key on a hotmail server.
All the computation need to be local and not remote.
This is very nice comparing to what others do: nothing.
The SMTP protocol have sucked for ages, and we applaud any action taken to improve it.
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.
I refuse to buy a handheld/laptop/desktop with MS software - such is my hate. Nonetheless, this is a great thing:
- They are going about it the right way (IETF rfc as an open standard, open source system)
- They have a lot of weight to actually make it happen
- This is something that should have been done a long time ago.
If they modified things from other proposals, I don't care. This is just something that simply has to happen!
So despite coming from microsoft, this is great news.
So umm, a service that MS wants every email server on earth to access, gets slashdotted?
Yeah this will work...
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.
Until some unknown point in the future, when spam-detecting systems are going to ramp up scores for emails from domains without SPF records.
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?
So now spammers need to forge the envelope as well as the sender field. No big deal. This will neither destroy annomymity nor stop spam. It just won't work.
It is; provided that you share the changes you make.
UNIX/Linux Consulting
I have the impression that SPF is going to create a lot of problems to universities.
A couple universities I've been to do not allow external SMTP connections. Users need to use their ISPs' SMTP server to send email. I couldn't find how the SPF can accomodate this practice without significant change: either the university allows authenticated external SMTP connections or ISP provides another authenticated SMTP server for these users (to user whatever address they want).
A sig is redundant.
I think it's going to be hard for folks in your position, but not impossible, and there are benefits to it. I am a sysadming in IT as well so I am sympathetic to the problem of getting thousands of users to change.
Here are some ideas that may help.
1. Identify the networks you control and list those. If you know all the mail servers, great, list those... but if you don't, you can also get by with just listing the network ranges that you own and that allows any server in those ranges to send.
2. Offer mobile users an SMTP AUTH server. This will allow mobile/roaming users to send outbound mail back to corporate HQ to be sent out, rather than sending out through whatever DSL or cable ISP they happen to be on.
3. Phase it in slowly. Add ?all to the end of your record to allow sending from anywhere. There are additional optional things you can do to detect when mail is being sent from servers you haven't approved yet... You can do something like altavista.com does -- they use "exists:" in the record to trigger a second DNS query and then they can log those queries.
SPF is all nice and such, but it won't help stop spam at all. All it will do is encourage spammers to use other forged domains that don't have SPF records (which is most of them.)
Adoption of SPF or other technologies (domain keys for example) needs to be near 100% to be useful in reducing spam. Lack of records can be somewhat useful as a scoring tool in spamassassin for example, but that's about it. Spammers will just find another way to spam - maybe they will start publishing SPF records on the 8782374651872356 domains that they have registered or taken over.
Spammers already control a large percentage of windows machines - they really don't care if what they are doing is illegal or not. Grandma's machine will start spewing spam using her real email address via her ISP slowly - a few dozen messages every day. Of course there are millions of other grandmother's machines to use.
If you control the domain that your email is from, then you simply need to change the DNS settings for that domain to add the proper SPF record.
Basically it's like this.. You have a domain like example.com. You send email from bob@example.com. But you want to send email through some other SMTP server, call it smtp.com, for whatever reason, and keep the From: line as bob@example.com. Since you control the domain, all you need to do is to change the DNS settings for your domain to add SPF records that say "smtp.com is a sender of email for example.com".
Problem solved. When a SPF enabled receiver gets your email, they query example.com's DNS, read the SPF info, see that it's okay for smtp.com to send email for that domain, and all is well.
Now, if you don't have access to your DNS records on that level, then I seriously suggest a) griping at your domain host/provider to let you have that sort of access, or b) switching to a new provider.
In the short term, however, this won't affect you at all. Not having an SPF record essentially means that the default will be used by SPF enabled receivers. The sane default, for the moment, is to allow email from anywhere in the event that SPF records do not exist on the domain in question (assuming SPF is being used as a straight block/no-block type of method, as opposed to a weighting factor in some spam prevention algorithim).
In the long term, eventually everybody will have to implement SPF if they want their email to be received by SPF enabled systems. But that's way, way long term.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
In my mind, Sender ID and SPF have nothing to do directly with spam. They are designed to combat fraudulant e-mail headers, nothing more.
Granted, almost all of the current spam has fraudulant headers, but if Sender ID and SPF catch on, that will gradually change. Spam will simply be tagged with the correct relay.
One could say that illegal spam will be easier to track down, but that isn't really true... you can track spam with excellant accuracy today by following the linkage to the company selling the products. That linkage has to be accurate, or there is no profit to be had.
You could also say that spam will be easier to blacklist, but I don't think that is true either. Simple shifts in the spammers' methodologies, such as rotating their DNS names, would suffice to get around blacklists.
What we really need to combat spam is better e-mail management tools. The reason we get unwanted e-mail is because the sender has control, not the individual or company. That needs to change.
Would a large company allow a random outside person walk into their building, go to anybody's cube, and start talking? Never, but that's what happens electronically today with e-mail.
Instead of today's simplistic systems, imagine a multi-tier system of contacts -- a top level of corporate maintained partners and customers, a mid level of department specific contacts, and a bottom tier of personal contacts and exceptions.
This contact list would be paired with a routing system based on well-defined business rules. As companies regain control, the From will become far more important than the To.
But sophisticated management depends on clean data, and clean data is exactly what today's e-mail isn't.
The more checks we can add into the process to validate the headers, the better the tools can become, and the sooner unwanted e-mail will become a thing of the past.
WHy do you need a new ISP? just get an email from Spymac.com, or gmail if you have friends. Theres someting out the that allows you to access gmail via POP and spymac give you POP access out of the box.
The only downside I can see is that you'll loose your email and need to inform every one of the change, but then you were planning on doing that anyway. If you're happy with MSN dial-in but not the email just use one of the ones above.
Alternatively you could NOT use outlook (any version) and use Thunderbird link instead.
Just some idea you can try, and maybe avoid the hassle of changing ISP's.
face the world with eyes of fire.
Setting Sender: is one way around mobile/roaming problems, but not the only way.
Probably the best fix is to use SMTP AUTH to connect back to your home server, and it can send the mail out from there in the normal way.
I quote from the "sender-id" page linked to from the SPF site:
If you are a software developer and are interested in implementing this specification in software, please review the terms of the Caller ID for E-Mail Implementation License before you begin, as the patent license discusses the rights that Microsoft would grant you or your organization. Please note that a license agreement is not required for individuals, companies, or ISPs who only wish to publish their Sender ID records.
I think SPF is the shiznit, So does MS, thats why they're tying themselves to the protocol. I just hope this is not going to be another Samba fiasco