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."

Comments

I publish SPF records

[karl.auerbach]

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.

Re:boo

[Anonymous Coward]

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

Re:Some of us have reasons for spoofing our addres

[pe1chl]

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.

Why this is a big deal

[mattbee]

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.

Re:Why this is a big deal

[jeroenvw]

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.

So, as a spammer, you only have to publish an SPF for your own domain, and your mail is garanteed to be nonspam?

No, you have it wrong: Mail coming from hosts not allowed by the SPF, is guaranteed to violate the policy of the sender domain. SPF is basically saying: ``Hey, to whom is interested, mail coming from one of oud adresses, will always be send by these mailservers. So if you receive them from other means... We didn't do it!''

But indeed, if the domain and its users are trustworthy, you may decide that spam isn't likely to come from them. While ISP's might be trustworthy themselves, their users as a whole are not.

the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.

Wrong again, it's about mail flowing FROM @aol.com adresses. Mail going TOWARDS aol has nothing to do with it. Even if AOL will be implementing SPL while recieving mail themselves, if you don't use SPL, you're not blocked, and also, you need to change your DNS, not your mail server, if you want to implement SPL for outgoing mail of your domain.

Re:Why this is a big deal

[Malc]

Check the FAQ. The topic heading is "But that breaks forwarding!"

Re:Why this is a big deal

[Zocalo]

Just a quick clarification, but an "SPF record" is not, strictly speaking, a DNS TXT record type. The SPF RFC defines a new DNS record type called as you might expect, "SPF" which is the preferred way of doing things:

@ IN SPF "<spf string>"

However, in order to get things off the ground without having to wait for DNS servers and tools to support a new record type, it is also possible to publish the same information in a TXT record:

@ IN TXT "<spf string>"

If your DNS server supports the SPF *type*, then you should ideally use that and provide the TXT record as a backup. Query tools that properly support SPF will probably look for the SPF type first and then requery for TXT on a failure, but it's up to the developer of course.

Re:boo

[krymsin01]

Nice trolling

This does reduce spam

[dybdahl]

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.

Re:How does this reduce spam in any shape or form?

[krymsin01]

You are doing a reall good job at copy and pasting past comments for karma whoring.

I bet your parents are proud!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Spamassassin will support it in 2.70

[KjetilK]

Hm, I must have been living under a rock, because it is the first time I hear about it. However, it sounds like a good idea, I have to contact my upstream ISP to have them add a record for me.

Anyway, it seems SpamAssassin will be adding support for SPF in 2.70, at least according to bug 2143. That's cool!

Re:boo

[afidel]

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.

It does seem to work

[Erik Hensema]

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

Re:Would someone explain this to a simpleton?

[Motherfucking Shit]

I read the page but it's too early in the morning for me. Would someone please explain the idea behind SPF _understandably_?

Suppose you own a domain, let's call it sharpfang.com. You have a cable modem and your IP address is always 24.95.x.x. If you're sending out email from sharpfang.com, you always do it from your cable modem.

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.

Re:Dynamic IP addresses

[Motherfucking Shit]

This is not going to work for domains that have dynamic IP addresses.

Sure it is, you can specify CIDR notation within your SPF record. This lets you cover the pool of IP addresses that you (or your users) might be assigned. Check out AOL's TXT record:

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"

Instead of listing every IP address that a legitimate piece of AOL mail could possibly come from - which would be a slight bit bulky for DNS - they've specified a bunch of /24's ("class C's") where their SMTP servers reside.

AOL will likely remove these SPF records today

[wayne]

According to a message from Meng Weng Wong (the author of SPF), AOL will likely remove these SPF records today (Friday). There are still kinks that need to be worked out, and AOL doesn't like to make big changes like this to be permanent and/or last over the weekends until more testing has been done.

See: this message on the SPF mailing list

SPF is NOT a problem for you,

[autopr0n]

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?

Breaks Forwarding

[n-baxley]

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.

Re:Tag it

[Daniel_Staal]

I know that Moz supports acronym, abbr and a with title attributes, however IE is the most used browser (much to web standards proponents chagrin) out there and does not support all of the afore mentioned tags.

More pertentely in this context: Slashcode doesn't support it. Even if the original submitter included it in their submission it would have been stripped out before it got to the editors.