Slashdot Mirror
AOL Now Publishing SPF Records
SPF Fan writes "It looks like SPF is starting to catch on with the bigger ISPs. AOL is now publishing SPF records which you can verify with 'dig aol.com txt'. Will Hotmail and Yahoo be far behind? Who else is publishing SPF records for their domains? Slashdot has covered SPF in the past a couple times."
How does AOL know my SPF and why do they want other people to have access to it? Are they that concered at the prospect of me getting a sunburn?
Don't assume we all know what "SPF" is. Unless you mean "Sun Protection Factor", you are leaving the /. readers to wonder.
Please, if discussing a topic that is not widely known, put a short description or definition in the article writeup.
Thanks.
I have been pwned because my
[AOL]
Me Too!
[/AOL]
I've been publishing SPF records for the cavebear.com domain for about two months now.
I've only done the publishing side, I have not yet enabled my mail servers to use them.
Even though SPF may not be a complete or perfect solution, I see no harm in announcing to the world that if it purports to come from my domain than it also comes from my designated mail servers.
...thats 9 class c networks only for sending spa^H^H^Hmail
I only learned about SPF recently, but ever since I've been publishing SPF records for my domain.
It appears to be one of these "why didn't I think of that?" solutions that go and take care of a problem without ripping out everything around it.
Assorted stuff I do sometimes: Lemuria.org
In case any windows user is interested, but cant use dig:
$ dig aol.com txt
; <<>> DiG 9.2.2 <<>> aol.com txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49576
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;aol.com. IN TXT
;; ANSWER SECTION:
aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all"
;; AUTHORITY SECTION:
aol.com. 3071 IN NS dns-02.ns.aol.com.
aol.com. 3071 IN NS dns-06.ns.aol.com.
aol.com. 3071 IN NS dns-07.ns.aol.com.
aol.com. 3071 IN NS dns-01.ns.aol.com.
;; ADDITIONAL SECTION:
dns-02.ns.aol.com. 3273 IN A 205.188.157.232
dns-06.ns.aol.com. 1887 IN A 149.174.211.8
dns-07.ns.aol.com. 431 IN A 64.12.51.132
dns-01.ns.aol.com. 192 IN A 152.163.159.232
;; Query time: 110 msec
;; WHEN: Fri Jan 9 09:06:32 2004
;; MSG SIZE rcvd: 405
Nerds don't go out into the sun.
Ben
Work Safe Porn
I would advise you to read before you write.
SPF was invented especially to cater for your situation. The quick way out would have been to use MX records as the only validation, but this was not done.
It will reduce spam because of two reasons.
1) since it effectively kills sender forgeries, it's a LOT easier to maintain white/blacklists
2) a domain needs to be purchased, and the registration takes time; this increases the cost of spam and hopefully might also make spammers more traceable (credit card transactions for registration)
I am totally convinced this will make the spam problem manageable. I'll probably add my own SPF this weekend.
Spammers can just use their own domain
Yes, they can. And all I need to do is to let the domain be one feature to do adaptive filtering on. Two mails on penile enlargement, and no non-spam email from one domain, and that domain will be a pretty clear signal to throw stuff away. Time for the spammer to get a new domain.
Many will not implement this!
Well, whether everybody implements it or not, it does give me another factor to filter on. If the mail comes from a domain that does not implement it, that's grounds enough for a big, fat -5 spamassassin rule right there.
Oh, and as more and more people implement this, those who do not can be more and more severely punished by spam filters (as the exceptions for any one person becomes few enough to whitelist and so on).
But if you blacklist any domain without it, some people won't be able to send stuff to you anymore!
Cry me a river.
Trust the Computer. The Computer is your friend.
My own experience:
I happen to be hosting a few domain names that attract a lot of joe jobs, if this method helps me reduce the amount of joe jobs by 5%, it was worth it. The amount is simply HUGE.
The Deterring factor:
If the Spammers are smart enough to check my domain for SPF records before doing a joe job on it, they might not select it for their joe job, simply because they will know their campaign might not be as effective as it would be if they used another domain that does not publish SPF records. So the deterring factor is important here!
Conclusion:
Every effort counts. And let's not forget that sometimes, all it takes for an idea to catch on is some large corporation using the technology or technique, and it will catch like wildfire. I'm also publishing SPF records for my own domains, and checking for them as well (with the help of qpsmtpd which has a nice SPF plugin).
All those moments will be lost in time, like tears in rain... time... to... die...
> 2) Spammers tend to use made up domains anyways.
This is true, but combined with domain checking AND SPF I can see it being more powerful than both.
for ex.
spammer makes up umergeh.drewhs.com
email gets canned because the domain is fake. lose for spammers
spammer sends faked address from aol.com
SPF shows its a fake sender (rteal IP not match aol.com spf list). lose for spammers
spammer at aol sends real spam from aol.com
aol come down and bite spammers head off, spammer goes to jail. lose for spammers!
SPF is only one tool, and there are many combine them together and you have strength
mac desktops, dare to be nude
This just screws the people on dynamic IPs even more than we were before. I guess I'll have to keep paying a monthly fee just so I can have a smarthost to tunnel my mail through, since even more mail servers are going to think I'm a spammer now.
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.
Matthew @ Bytemark Hosting
As I don't think this will stop spam (at least not before massive adoption, as others said), I think it can protect us from having a spammer using our email address as From:.
I publish SPF records for my small domain now, and next time some dumb ISP complains getting spam "from me", I'll be able to tell them to go and check my SPF records, and to match these with "my" spam's headers.
Of course, this is for my little domain with few users, all well-educated enough to use authenticated SMTPS to my server.
blah
Nice trolling
stuff
Some people seem to be missing the point of spf. SPF is a mechanism that allows people to publish their own records to defend themselves against joe-jobbing. Anyone who has been joe-jobbed will be all over something like this. The fact that publishing these records benefits you directly, will help something like this spread in a timely manner.
It's also beneficial in the regard that when rolled out to where it becomes standard, mail will be far more accountable, and as spammers start joe-jobbing those people who have not yet published these records, it will only help motivate those hold-outs to get on the bandwagon and defend themselves.
AOL (and Hotmail, and other large ISPs) are frequently joe-jobbed - it's therefore worth it for them. If I can tell SpamAssassin to score anything above the threshold that purports to come from AOL, but not from their SPF IP allocation, it helps. Better still, now I can tell for certain that @aol.com mail really DID come from AOL, I can assign a negative score to AOL addresses since I know it's likely to be ham.
Oolite: Elite-like game. For Mac, Linux and Windows
It reduces spam because spamfilters like spamassassin etc. can add extra points to those e-mails that did not verify against SPF records.
If Red Hat adds SPF verification to their default spamassassin configuration files, a lot of companies will start to add SPF records to their DNS.
If I send an e-mail to a RoadRunner mailbox, it is rejected. Why? Because my mailserver is a Linux box on my ADSL internet connection, and RoadRunner blocks all e-mails from residential IP ranges. With SPF, such filtering can be made much more careful, making it possible for me to send e-mails to RoadRunner customers again.
You are doing a reall good job at copy and pasting past comments for karma whoring.
I bet your parents are proud!
stuff
Comment removed based on user account deletion
Anyway, it seems SpamAssassin will be adding support for SPF in 2.70, at least according to bug 2143. That's cool!
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Are you used to sending personnal email (one that have another domain than your employers in the From: address) from work using your company SMTP server as a relay? You know, the only one you have access to with many reasonable security policies...
Can't do that anymore, your message will be flagged as spam by the recipient server if he checks for SPF records.
Have AOL warned its customers of this little side effect of it implementing SPF?
Plus SPF technically wise sucks, it should have been a new record type using TXT records is an ugly kludge...
Comment removed based on user account deletion
As to your first point DNS is great because lookups are generally fast and they are cached. I don't think even every host on the internet looking up the TXT records for aol.com every couple of hours at the most frequent is going to tax the kinds of bandwidth and DNS servers AOL employs. Besides the amount of email traffic that they will be able to dump before the session even begins will outweigh the DNS lookups probably a million to one in bandwidth.
As to the second point that is already easily dealt with by most intelligent MTA's, heck my ISP's email servers already flag any message which has a different sending IP and host identifier, and they have informed us that they plan to dump the connection on this condition "real soon now". SPF just makes this easier since it can be used to eliminate false positives from semi-clued admins.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
of course you are right, but mods must understand too that a post must not be modded up because it seems clever, or because it repeats something clever someone already said before.
I can cite my Oreilly's books all day if I want to. Beyond the awkward morality of such guys (you can criticize /., but the best thing is to do it correctly), this brings nothing.
Repeating what you can learn by making your head work for 10 secs, it's ok. I'm not here for that.
Regards,
jdif
Let's overcome our weakness.
This is not going to work for domains that have dynamic IP addresses. Yet another reason we need to migrate to IPv6 and eliminate the need for dynamic IP addresses.
How about using the proper tag,
<acronym title="Sender Permitted From">SPF</acronym>
Or if you want to include it in a link
<a title="Sender Permitted From" href="link">SPF</a>
Comment removed based on user account deletion
1) Email worms
2) Zombie virus-infected mail relay clients
etc
If an experiment works, something has gone wrong.
You can have a personal list of "known good domains" with competent managers and SPF from which mail go directly to your inbox, without other spam filters. Safe knowing that mail from these domains really are from these domains.
You may even want to use a whitelist server ran by someone you trust.
What if I don't have access to the authorized relay, as in all company outgoing mail must go through company SMTP server, wether it as a @company.com from address or a @vanitydomain.com address.
If you read personnal email at work (bad) but keep it separate from your professionnal email (good) this will greatly inconvenience you.
And what about the consultant on a customer's site, if he don't have access to the authorized relay. He can't send mail while still having a perfectly usable SMTP relay at his disposition...
What do you think costs AOL more...?
1) Bandwidth & CPU for additional DNS lookups when people forge mail from their domain.
2) Bandwidth & CPU & staff costs for emails to their customer support desk complaining about the spam. (Bear in mind that the vast majority of users are not savvy enough to know not to complain to AOL.)
In an amazing coincidence I just implemented SPF filtering on my server yesterday.
This is what I got:
Jan 8 19:34:01 scrat sendmail[16839]: i08IY0ON016839: Milter: from=<larhondabeirne@aol.com>, reject=550 5.7.1 Command rejected
Jan 9 05:34:47 scrat sendmail[16305]: i094YlON016305: Milter: from=<krbsnag2gs@aol.com>, reject=550 5.7.1 Command rejected
Jan 9 08:59:45 scrat sendmail[25027]: i097xiON025027: Milter: from=<clairacree@aol.com>, reject=550 5.7.1 Command rejected
This is your sig. There are thousands more, but this one is yours.
Does anyone know how SPF can be managed via dynamice DNS type of DNS services?
It seems to me that having my reverse DNS lookup containing my ISP's domain name rather than mine would help my server configuration. I have a problem with my DNS in that reverse lookups are resolved to a DNS entry, but it belongs to my ISP domain and not my domain name. This gets some people pissy, but I don't see it being worth spending $100 a month extra from my ISP.
Would SPF help this problem? Would I actually be able to gain trust from others? Would DynDNS be able to accomodate this feature? (I'll have to ask them...)
I think a lot of this falls back to a much simply question: Why do we have DHCP addresses on the internet anyways? They do not change. I think mine is about 9 months old. Others tell of greater than a year with the same IP address. I think it would actually help security if people where give static IP addresses. Then they would have to take care of it to ensure they don't act stupid.
One day, you start getting a lot of bounced spam. Some spammer, for some reason, has decided that he would forge his latest batch of spam from @sharpfang.com email addresses. What a dick!
So, you set up SPF records for your domain. The SPF records are basically a way of telling other mail servers, "I only send mail from my cable modem connection, which will always have an IP of 24.95.x.x. If you get mail claiming to be from sharpfang.com, but it didn't come from an IP address inside 24.95.0.0/24, it's bogus!"
Now, enlightened mail server admins can reject any email with an @sharpfang.com return address but an origin IP of somewhere outside of 24.95.0.0/24. Of course, if your IP address or range changes (e.g. you're traveling, you switch ISPs) you simply update your SPF records in DNS.
SPF has dual benefits: it can reduce the load you get from joe-jobs (assuming some of the recipients' mail servers honor SPF), and it helps everyone else identify spam.
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
You can't spoof sender IPs - not for a TCP session like that required for SMTP anyway.
(Well okay, it's not quite true. You could just about manage to spoof IPs for machines on the same ethernet segment as you. However, if you're on the same segment as an outbound mail server, you're probably allowed to send via that server anyway.)
...SPF technically wise sucks
Agreed. I'm going to cut-and-paste the set of flaws I was talking about *last* time SPF came up on Slashdot:
First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is poisoned with false data, and the next N emails (until the cached data expires) are accepted as valid.
Second, this system relies on having everyone implement such functionality. Spammers don't give a damn about return addresses, so they can send email with a from address at any domain. The annoying and ineffective attempts at stopping all open mail relays on the Internet illustrate the failure of this model. A security system that relies on correct implementation over the full Internet to function properly will not work in real life.
Third, this fails to deal with throwaway domains. The authors waffle a bit about them, and finally come out and admit that more mechanisms are required. Dammit, if we had a good PKI trust-ranking system (which is the sort of thing that they are requiring to fix their failings) we wouldn't need this system at *all*, since we could simply sign email and have trust rankings for users.
Enough about the bad design: other reasons I don't like it include:
* The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.
* There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.
* DNS caching can make moving an SMTP server or setting up a new one take a significant amount of time.
* IP-based auth isn't a great idea anyway, for a number of reasons. The authors claim that it isn't a huge issue, because IP spoofing is harder (I disagree -- things like Mobile IP have made it harder to *block* IP spoofing).
* Users have no control over what gets blocked. If I *want* to receive email of a particular type, I can't. Two ISPs (sending and receiving) are the ones that determine what mail I can receive). This is perhaps acceptable within a company, but annoying and goes against traditional Internet structure.
* It does nothing to avoid compromised end user machines.
* It does nothing to deal with throwaway accounts.
* It does nothing to deal with misconfigured servers.
May we never see th
24.95.x.x would be 24.95.0.0/16. 24.95.0.x would be 24.95.0.0/24.
Thank you, carry on.
.
It seems that at the moment, spammers send mails to millions of possibly-active email addresses, in the hope that some of them are active. What's to stop a spammer making up possible addresses, querying SPF records for these (possible) addresses, and publishing the list of validated addresses? Can we now look forward :( to spammers using better address lists??
paypal, ebay, circuit city, bank of america, and microsoft all have reason to publish SPF records.
I'm only using windows reluctantly but this is ridiculous. You can do the exact same thing with nslookup, supplied with windows:
G:\>nslookup
> set q=txt
> aol.com
Server: XXXXXXXXXXXXXXX
Address: XXXXXXXXXXXXXXX
Non-authoritative answer:
aol.com text =
"v=spf1 ip4:152.163.225.0/24 ip4:20....
Anyway, I hope register.com hurries the hell up and lets me add these to my domains. I've actually been getting a bunch "recipient not found" messages going to [random word]@[mydomain.com] (not autpr0n.com, either my personal domain) meaning someone is spamming and using forged address claming to be from my domain
and for each bounced message, who knows how many are getting through. A friend of mine (an AOL user) actually had a spammer us his personal email address, and got not only a bunch of bounces, but angry emails and IMs.
The sooner this goes into effect, the better. It'll probably be a long time before we can block all email that doesn't come from a domain with SPF, but hopefully soon we can get rid of emails that are explicitly not authorized. (like those claming to be from my servers...)
autopr0n is like, down and stuff.
Question on this whole SPF thing.
I'm interested in it but have a slight issue with it at the moment that
I'd like to get resolved.
My domain is: mydomain.com
Customer A is traveling and is using his e-mail of joe@mydomain.com
However, I do IP filtering on my mail server (not SASL AUTH), for my
dial-up pools.
When Customer A is at hotel he must use their mail server to send mail
out, so his mail will be rejected because the hotel mail server isn't
listed in mydomain.com's SPF txt list.
You suggest running SASL AUTH as a work around for this, however in my
experience this creates MORE of a spam problem then not using SPF..
here's why:
On a mail server with over 40,000 users it's relitively easy for someone
with a password cracker to hammer away at common names like 'joe'
'jeffp', etc and try to get some passwords. Once they have a
username/password combo they can happily send e-mail out as that user
through MY mail server, and I can't do anything about them. Doing IP
filtering requires that they are on MY network to send mail through MY
server, thus allowing me to terminate/prosecute/etc the person.
Actually, that wouldn't work -- other SMTP servers have no way of knowing which port your SMTP server will be on, so it is hardwired to port 25. You wouldn't be able to receive any e-mail.
See: this message on the SPF mailing list
SPF support for most open source mail servers can be found at libspf2.
For instance, the box on which I get all my mail, to which all my mailing list subscriptions go, and which is associated with my online identity everywhere I have one...is located halfway across the continent from me
Two solutions.
1) The "hard" but proper way, setup SPF records from all the machines you will be sending mail from or
2) Simply send all your mail out through the box you get it in from. What's so hard about that?
Anyway, I'll be happy to let anon mail through just for your convenience, so you don't have to setup SPF once every 6 months, or wait for your email to get forwarded through your own mail server, if you'd be willing to go through and delete the hundred or so SPAMs I get each day. Sound like a fair deal?
autopr0n is like, down and stuff.
First of all, why can you use the machine you receive mail on to send mail? Obviously that IP doesn't change too often.
And in any event, most dynamic IPs are within a certain net block. so you can simply add that net block to your SPF record. I'm assuming you have your own domain here.
autopr0n is like, down and stuff.
The biggest problem I can see with this is that it breaks forwarding. I have several email addresses that I don't use anymore but that I still get email on. If I take the SPF people's recommendation and just remail it, I lose the sender information, or at least lose access to it when listing my emails. It would be nice if this could handel forwards as well.
THIS SPACE FOR RENT
As a matter of fact, there is nothing stopping spammers from registering a bogus domain, and making the entire internet part of their SPF
But it kills domain forging; they have to use their own bogus domains which can be quickly and easily blacklisted by other methods if they spam a lot. SPF says "This machine can be held accountable for mail sent for this domain," there's no magic if you're not willing to actually hold people accountable. But the contrapositive to that is, if someone says they're host is accountable and mail from that host is otherwise sound, then you should give them the benefit of the doubt.
What is needed is SPF and some sort of a trust between domains.
Mechanisms based on trust are either expensive or doomed to failure. So it has always been and so it will always be.
Unfortunately the W3C's sites seem to be ambiguous about this. However, somewhere it does state that ACRONYM is for pronouncable acronyms and ABBR is for unpronouncable acronyms and abbveviations (although I can't find the link to back this up). They probably could've made this less confusing, but they didn't.
At http://www.w3.org/TR/html4/struct/text.html#edef-A CRONYM where they actually define the standard, they give WWW as an example for ABBR.
Again, I'm just saying it's ambiguous, I'm not trying to start a flamewar.
I remember when legal used to mean lawful, now it means some kind of loophole. - Leo Kessler
pobox.com doesn't know any of these IP addresses, so if they *do* advertise SPF records for *@pobox.com, anybody who listens to SPF will reject me, and probably most of their other customers. It's fine for them on the input direction - blocking forged aol mail, for instance - but even that prevents you from sending mail From: you@yahoogroups.com when you want the replies to go to your yahoo address, not your real address, which can be important if you're sending to people with dubious Microsoft mail systems that might ignore Reply-To: or people who don't pay attention to message bodies that say 'Please reply to my yahoogroups address, not my work address" (like your mother-in-law on aol.)
For someone like Karl, I'd expect that the risk is that if you're using a dialup connection that requires you to use _their_ SMTP relay, or if you're on a hotel broadband connection that hijacks SMTP, you'd risk having some people block your mail. Hopefully SPF-using SMTP servers do so noisily and not silently...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Simple Authentication and Security Layer allows a user to identify themselves to a mail server. POBOX just needs to set up a mail server that uses SASL and then their users use that to send mail.
This is often referred to as SASL auth or sometimes SMTP auth.
They probably need to set it up on both port 25 and another port generally 587 in case users ISPs block connections to port 25.
Alternatively there are older solutions that may work for some mail services like POP before send. Where any IP address that has successfully logged into the POP server can send e-mail through the mail server for a certain period of time.
Basically once SPF catches on public mail services need to run their own mail servers. This makes sense, it's their e-mail and they should be responsible for sending it.
In the case of pobox.com seems to already be running SASL:
% host -t a sasl.smtp.pobox.com
sasl.smtp.pobox.com A 64.71.166.114
pobox.com is already publishing SPF records so it looks like they think it will work for them.
% host -t txt pobox.com
pobox.com TXT "v=spf1 mx mx:fallback-relay.pobox.com a:emerald.pobox.com ?all"
They are specifying the loose "? = unknown" for servers other than their own, but it is up to the receiving MTA to allow or deny "unknown".
They are following the SPF adoption strategy:
"Initially, domain owners can set ?all, which means "default unknown". They start educating their users to switch to SASL AUTH, and maybe set a local sunrise date.
When the vast majority of users are doing the right thing (sending mail out only through the domain's designated mailers) they change the default to -all, which means "default deny". That tells SPF-aware receiving servers that it's safe to reject SPF violations rather than classify them as spam."
This message is encrypted with Quad ROT-13 to protect the author's copyright under the DMCA.
Oooh, wow. I didn't even think of that. You're right. That's *incredibly* nasty -- someone spoofing DNS responses containing SPF records could take down, say, all AOL to MSN email for however long the SPF records stay cached. With one packet. Without even needing to flood any system, since we're talking UDP, not TCP.
May we never see th