AOL Now Publishing SPF Records 340
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."
Suggestion for submitter (Score:4, Insightful)
Please, if discussing a topic that is not widely known, put a short description or definition in the article writeup.
Thanks.
Re:Suggestion for submitter (Score:4, Insightful)
He did provide a highly visbile link to the definition of SPF. That page gave a very good overview of the topic. Why cater to (define NOT_FLAMEBATE)lazy people who don't read the articles?
How about dynamic IPs? (Score:4, Insightful)
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 (Score:3, Insightful)
Re:Observe the missing link (Score:3, Insightful)
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
Re:SPF is a really bad idea (Score:4, Insightful)
See step 2 on the "How do I implement SPF" [pobox.com] page.
Tag it (Score:5, Insightful)
<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>
Re:How does this reduce spam in any shape or form? (Score:3, Insightful)
2) Zombie virus-infected mail relay clients
etc
It makes whitelists work better (Score:3, Insightful)
You may even want to use a whitelist server ran by someone you trust.
Re:boo (Score:2, Insightful)
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.)
SPF as a spammer tool? (Score:2, Insightful)
I see a problem here.... (Score:5, Insightful)
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.
Re:This is a good idea (Score:3, Insightful)
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.
How dynamic are we talking about? (Score:3, Insightful)
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.
Re:Other problems with SPF (Score:3, Insightful)
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.
Re:Make/break it (Score:2, Insightful)
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
Re:Suggestion for submitter (Score:5, Insightful)
Well, one reason would be that linked articles often get slashdotted before most people get to them. Another is that some would like a brief heads-up without having to read an entire treatise on the subject. But then, real geeks know that keeping outsiders in the dark is the key to their mystique...
Re:Why this is a big deal (Score:3, Insightful)
So it was. My mistake.
Re:SPF && DYNDNS (Score:3, Insightful)
The SPF DoS hole (Score:3, Insightful)