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."
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
That's good news!
Anyone can develop standards, but still it's the ISPs that can make it or break it. Big ISPs can push some standard, and force the whole internet to use SPF or be cut off.
.sig: No such file or directory
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
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.
You wouldn't. But that is part of the problem as legitimate uses can't be differentiated from SPAM when taking this approach.
Its one of those great "lose liberty in the name of enforcement" style things.
Or of course you could just set up SMTP on that remote server of yours.
An Eye for an Eye will make the whole world blind - Gandhi
We have dig for Windows too, no need for the holier-than-thou attitude.
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
Nice trolling
stuff
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
If you're on a dynamic IP you'll find a lot of your email gets bounced by Yahoo/AOL (at least) already for being on a dial-up blacklist. You simply can't send mail reliably from a dynamic IP these days, but I won't miss the spam.
In the UK we have plenty of choice for broadband ISPs who offer fixed IPs at no extra cost (which is why I'm moving away from BT Openworld who charge an extra 10 a month for the privilege)
Matthew @ Bytemark Hosting
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
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.
I think that's why "SPF" was a link to a site explaining all about it; you could try CTFL. Of course, nobody here ever reads the stories before posting much less clicks the links.
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
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.
Nonsense, the message body doesn't come down the pipe as the checking would be done before the data part ever starts.
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.
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.)
According to the site, DynDNS lets you publish SPF records if you want to. Don't know if you have to pay extra, but DynDNS is pretty reasonable :)
- Oliver
The right to bear arms is only slightly less stupid than the right to arm bears...
Wrong. This helps you because it provides a method by which an SMTP server could discover that email claiming to be from you that is also originating from your dynamic IP range is legit.
You should read the SPF RFC. I just did, and just added SPF records to my DNS server. SPF includes support for specifying other IP ranges, domain names, and even specifying exceptions at a per-email-address level to address cases where someone has no idea what country they'll send email from next.
I'm a skeptical bastard with an extreme dislike for change, but a few hours after hearing about SPF for the first time, I'm serving '-all' SPF records from my domains. I was able to see it was a good idea when I finally understood that
SPF records provide a way to recommend restrictions on those who attempt to spoof your domain in their outbound email.
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.
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.
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
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.
'Sensible' is a curse word.
Same here, even worse. Earthlink (my access provider) blocks access to non-earthlink name servers, so i can't query AOL's dns. ;-(