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."
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
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.
Comment removed based on user account deletion
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.
SPF implementation guidelines specify that admins specifying their SPF records should also enable SMTPS authentication. With this you'll be able to send your personal mail from everywhere using your domain's SMTP server.
See step 2 on the "How do I implement SPF" page.
blah
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>
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 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.)
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??
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.
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 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.
Less annoying then hundreds of SPAMs a week.
* There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.
Yeah, that is a problem. I can see spam-hat hackers attacking widely used DNS caches in order to poison them. But that would make SPAM even more illegal, and lots you could seriously get a fraud charge by doing that.
* 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).
Another good point. Perhaps in the future, if SPF on IP isn't enough, we could move to have mail servers automatically sign all mail that comes out of them. Check the signature with the ISP. It would be resource intensive. But if SPF doesn't do what we hope based on IP we might need to do that.
* 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.
Wrong, SPF can easily be implemented at the mail client site. Everyone should be running their own mail server anyway.
* It does nothing to avoid compromised end user machines.
It does. It will be impossible to send mail from a compromised host without 'claming' those hosts as part of your SPF record. If you include the entire 'net in your SPF record, then you're as good as not having one, and most implementations will treat you that way. If you include those zombies directly in your SPF, it's obvious you hacked 'em.
And at any rate, most domains that claim spam will quickly be blacklisted.
* It does nothing to deal with throwaway accounts.
The domain that claims those messages will mostly likely be blocked. A distributed domain blocking list will probably catch a new spam domain in a couple hours (coming down extra hard no new domains). This technique is impossible without SPF.
* It does nothing to deal with misconfigured servers.
Other then getting the domains blacklisted, and the mail servers reconfigured correctly. Hopefully SPF will make the blacklisting business a lot less harmful then it is now.
autopr0n is like, down and stuff.
And this is one standard I hope they will break, as it's designed to work only in the majority of the casese, and has the potential to KILL valid and important 10th percentile email.
What about sender addresses without a FQDN (fully qualified domain name)? There's local addresses, special addresses (like for bounces to prevent double bounces), IP literals (like someone@[123.45.67.89] and bang paths (like foo!bar!baz!someone). And X.400. And a lot of other reasons. The domain name might even be dynamic. The mail server might be dynamic(!).
And no, you can't be sure that if the sender address domain has an SPF which matches a Received header, the mail isn't spam. For several reasons.
Inserting fake Received headers are common enough, and there's no standard for which order they're added in, although MOST MTA's will add to the top. So the MTA's who follow the standards but don't do it one particular way are fubar'ed then?
Then there's the question of just *which* header to parse. The envelope FROM? The From:? The Sender:? The Reply-To:? The Errors-To:? All of the above? The only one you can be certain exists is the envelope FROM for external mail -- for internal mail there's no telling.
And how can you trust the DNS? A favourite tactic of spammers has always been to hack a DNS server. This is just going to increase if this takes effect.
Finally add to this just *who* came up with this brilliant suggestion. Some people are better at glorifying themselves than thinking things through, and quite frankly, this will help HIS business, but hurt a lot of others who RELY on the SMTP standards. If someone wants to come up with a system for authenticating email, fine, but don't jam it into SMTP unless it can be done without ANY disruption to existing SMTP procedures.
--
*Art
So it was. My mistake.
ips are often assigned based on the network card's physical addr. Some cards have setup software that allows you to change this number. Try changing it, restart your dhcp client and see if the tcp/ip addr has changed. Set it back and see if you get your old tcp/ip addr back. RR in Columbus seems to work this way. When I have installed a new firewall, just moving the old network card to the new machine lets me keep the old tcp/ip addr.
FreeSpeech.org
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