Slashdot Mirror
AOL Tests Sender Permitted From / E-mail Caller ID
securitas writes "ZDNet reports that AOL is testing Sender Permitted From (SPF), 'an antispam filter intended to accurately trace the origin of e-mail messages.' AOL is performing the widescale SPF test with its 33 million subscribers worldwide. The system works by letting recipients use the SPF record to cross-check DNS data associated with AOL's IP addresses and confirm that the message originated from AOL's servers. The system is one of three competing e-mail authentication protocols. The other IP-identifying protocols are the Designated Mailers Protocol (DMP) and Reverse Mail Exchange (RME/RMX). All systems alter the DNS database to let e-mail servers publish the IP addresses that they use to send e-mail."
I like how AOL has recently been classifying all email from my domain as spam, making it difficult for new users who are expecting their registration confirmation in their mailbox to actually complete their signup on my site. Or to get their important notices that, like, their transactions (with other users - it's an auction site) are completed.
I get a half dozen AOL users complaining that they never get their registration or notification emails every single day. And, of course, I can email them to tell them that it's an AOL problem, because AOL will filter that out, too.
So.. basically. Fuck AOL up the ass.
This is not a whitelist filter.
It's not any kind of a filter.
It just means that AOL has published SPF records for its mail servers in their DNS entries. Any mail server speaking SPF, receiving mail from AOL.COM, will check the SPF record.
If the SPF record (which will contain the IP addresses of AOL's mail servers) doesn't match the originating IP address of the mail message (as in, a spoofed header) the message is invalid. Then it can be either dropped or bounced or whatever.
If the SPF record matches the initiating IP address (as in the case of a message legitimately sent by the mail server) it's clear and goes through.
Don't forget to publish SPF records for your domain if you have the ability to do so. If you have already done so, please register your domain via the validator.
Prevent email address forgery. Publish SPF records for y
See: this SlashDot post story
Prevent email address forgery. Publish SPF records for y
Heh. Actually (if I have understood correctly) SPF should prevent anyone from spoofing aol.com as the sender address during the SMTP session. So if a spammer attempts to spoof aol.com and your mail server is SPF-aware, then it would be good for you and AOL because you won't get spam and AOL won't get bounces for the addresses that had problems with delivery (and with spam, problems with delivery are not rare).
At least this is how I have understood it.
That seems to be by design. (Not offering an opinion, merely commenting. Seems to me all these schemes will cause much more pain for the small guys than for the big ones.)
Prevent email address forgery. Publish SPF records for y
It means that any system administrator can configure their mail transfer agent to bin any spam pretending to come from aol.com with a 100% success rate. And this goes for anyone else publishing an SPF record for your domain.
SPF is a proposed standard for a domain owner to tell mailers where mail From: that domain may originate. The domain owner publishes a DNS TXT record for their domain with (at the simplest) list of IP addresses. Participating mail transfer agents can then look this record up and make a policy decision on whether the mail is likely to be legitimate. The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.
SPF is not a wholly original idea (e.g. up "designated mailer protocol"), and certainly not the simplest implementation but the important factor is that its proponent, Meng Wong, is an excellent lobbyer and spokesperson, as well as someone who as the nous to put forward a useful protocol (he founded pobox.com). It's currently at the point where lots of implementation are being written, with the canonical version being Meng's Perl modules. Currently I'm helping to finish the C implementation which will shortly be integrated into qmail and exim.
The tipping point (I hope) will be when a domain not publishing an SPF record or publishing a globaly permissive one will be considered "obviously" untrustworthy. Combining SPF authorisation with a more traditional "From: domain blacklist" will give spammers a very very hard time indeed forging mail. But AOL publishing a record (we hope) shows the way the wind is blowing: the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.
So go on, it's dead easy, publish a record for your domain now. Tell people where your mail comes from. Look, there's even a wizard to help you.
The receiving mail server just asks the originating domain DNS for the list of allowable IP addresses for originating mail. Then it verified the e-mail it just received came from one of the allowable IP addresses.
The recipient's MTA will check the sender's SPF record. You can auto-generate all the email accounts you'd like, only the domain name portion of the email address is authenticated in SPF.
In fact that was one of the arguments against SPF, people said that it did not go far enough and actually authenticate users.
Personally, as someone who has to administer an email server and whose domains are sometimes used in forgeries for spam ( last one was a few days ago ), I'm all for SPF.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
SPF is just one tool to help tighten up the security of the SMTP system. It lets domain owners say who is authorized to send email using their domain name. This is a useful thing to do, and it allows for other things to build on it. For example, RHSBLs that blacklist domain names instead of IP addresses are much more useful after SPF checking has been done. SPF checking can also help detect phishing schemes.
SPF support for most open source mail servers can be found at libspf2.
How is this any different?
You can work-around either by using VPN or something similar.
If you don't like the way your ISP handles it, complain or switch ISPs, just like you would now. ISPs aren't regulated. And if they were you'd be complaining about something else. Deal with it.
SPF should work very well for the time being, much more effective than any algorithm that looks at a message and tries to determine whether or not it's spam.
This is a great feature! I never understood how it would really work until I started using Shadango (based on a recommendation posted on /.)
See, I generate a disposable ("Spamtrap") account, and post that all over the internet. When the crap gets too unbearable, I just regenerate it. I can't even imagine how I survived without a disposable account in the past.
Also, and more related to the story, what will happen to sites that let you consolidate all your other accounts? I use Shadango to check my POP/IMAP/Y!/Hotmail/AOL/mail.com accounts (because it filters them, plus I have a bigger quota), but I guess it's just a matter of time until I won't be able to 'send' from those addresses anymore.
Hmmm... it sucks that spammers have slowly taken away all the freedom that the email
It's hard to win a fight when you don't know who to swing at.
Susie Johnson
New: 2911 Total: 8639
That is from the last 6 weeks. Less than 1% are real messages (domain renewals).
Before looking at SPF you may want to read what Claus Assmann [theaimsgroup.com], and Wietse Venema [theaimsgroup.com] have to say on the subject.
You might also want to read what Steve Bellovin (one of the guys who invented USENET among other things) and Eric Raymond have to say about it. They spend a little more time understanding SPF...
Wired story with Raymond's comments.
Bellovin's comments in an email to the SPF mailing list.
The idea behind Internet Mail 2000 [cr.yp.to] is obviously correct. Why waste time on DNS-based approaches when we COULD be developing the Solution?
Because it's not backward compatible.
SPF is a simple and backward compatible solution to email forgeries. People who don't use it are still able to use email, while people who use it are protected against forgeries.
Everyone and their brother are reinvented email theses days without realising that you need to improve the existing email system. It's not possible to throw away the existing system.
I've read the article and I can't figure out what the test is. Does this mean that AOL is publishing SPF records (in which case it's old news) or does it mean that AOL is going to start rejecting incoming mail which fails the SPF tests?
It's the old news.
Because his solution has flaws which he continues to ignore and nobody is interested in implementing it.
Well, in the near-term, SPF won't do anything to slow the quantity of spam. Regardless of what the most die-hard rabid supporters would like everyone to believe.
SPF is an attempt to stop the practice of domain-forging or "joe-jobbing". Which, for a business domain is important. Right now, anyone can pretend to be joe@mycompany.com and either tarnish our company's name, or simply make life extremely difficult for us when our ISP cuts us off for spamming (when we didn't do it).
However, it is likely to have some beneficial side-effects like making domain-based whitelisting/blacklisting more effective. It raises the bar one more notch for a spammer (now they have to either find a non-protected domain to forge, route their spam through authorized servers for a domain where it's likely to be noticed and blocked, or register throw-away domains to push their product).
(And SPF is very similar to what AOL already requires if you want to have your domain whitelisted with them. You're required to list the IP addresses that send outbound e-mail for your domain, anything else gets dumped in the bit-bucket or at least is likely to get tagged as spam by the filters.)
Wolde you bothe eate your cake, and have your cake?
Not true.
AOL's SPF records 'whitelist' their own servers whilst saying nothing about the rest of the net.
This means that mail sent from @aol.com addresses via AOL's servers can be treated as authentic by spam filters, whilst any mail sent by other means is treated exactly the same as before (ie maybe forged, maybe not).
I don't understand... why can't all email servers just check forward/reverse MX record lookups to help deminish spam. I know that will not end it, but it would drastically help from spoofing email... which is all that AOL's initiative seems to be doing (i.e. not killing it, just preventing their servers from being spoofed).
Initially, that was my question too... why not just require that outbound e-mail be sent from an IP address listed in an MX record?
Well...
1) MX records are designed to specify what IP address will accept mail for a domain
2) A lot of companies use seperate outbound mail servers that are not capable of receiving e-mail (and thus aren't attached to an MX record).
Oh, yeah, and have the email servers not accepting relays, and patch the damn home user windows boxes. Instead of AOL blocking ADSL, they just need to block windows '95-ME, 2000 pro, and XP. They are all home systems, not servers. Network packets can show OS footprints, so this is doable.
Read up on the SMTP protocol, an SMTP server knows *nothing* about the connecting host other then IP address and what the host chooses to identify themselves as in the HELO/EHLO command. (Or by doing a reverse lookup on the IP address, which isn't very informative.) In fact, scanning the connecting host to determine its "footprint" might be considered a misdemeanor/felony under some interpretations of the law.
Just more media hype, I'll beleive it when I see it. AOL just has to rebutt microsoft (MSN) from stealing more AOL users with their latest news about anti-spam pledge from Gate's.
AOL has been testing SPF since well before Microsoft/Gate's announcement last week. In fact, AOL already has a program in place where you can whitelist a domain with them and specify what IP addresses are authorized to send outbound e-mail for your domain. They're probably tired of maintaining that list when SPF could store the information in the DNS system and make it easier on everyone.
Wolde you bothe eate your cake, and have your cake?
No, it doesn't break forwarding as long as every hop's SPF is properly defined. The include keyword in SPF lets you specify the mail servers that relay mail for you, and so on.
Of course, this opens the possibility of extremely long include chains that would keep your DNS busy for ages, but hey...
You're missing something obvious, which is that list messages come from the list server. The cosmetic header From: is still you, but it's From (no :) the list. The FAQ explains it.
- RustyTaco
SPF is based on the envelope sender not the From address - I suggest you read the FAQ first.
Yes, you have to change the envelope on each hop, but that's a good thing, as it means that each hop is validated which makes it harder to spam.
People through FUD around to mean any sort of bullshit, but, yours is the first real, bona fide FUD in a while :)
The problem with people of your ilk is that you don't understand the difference between an envelope from and a header from.
SPF works on the envelope from (you know, as transmitted by the MTA, often using MAIL FROM if we're talking SMTP), not the thing that's listed in the "From:" header of the message.
When a message is forwarded by a mailing list (or by your MUA), the From: header may belong to someone else but the envelope from is yours... and, of course, that's what's checked against SPF.
In other words, the list's SPF records will be checked against the list's domains, not your records against your domains.
Not really.
If you use the smtp server (with authentication) provided by whoever owns the domain name on your 10-year-old email address, and they set up SPF, you'll be fine.
SPF doesn't have anything to do with what IP address you connect to the smtp server from. It just validates the smtp server.
It just means you can't use your own local mail server to send from a domain you don't own.