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."
Catching on (Score:3, Interesting)
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.
Re:How does this reduce spam in any shape or form? (Score:5, Interesting)
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.
Re:How does this reduce spam in any shape or form? (Score:5, Interesting)
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 [nsa.co.il] which has a nice SPF plugin).
Re:boo (Score:5, Interesting)
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 [scrounger.ath.cx]
Re:How does this reduce spam in any shape or form? (Score:1, Interesting)
anti-spoofing (Score:5, Interesting)
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.
Some of the benefits. (Score:4, Interesting)
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.
Re:How does this reduce spam in any shape or form? (Score:3, Interesting)
Theres plenty of existing (Score:0, Interesting)
Including anti-spam features (not just anti-relaying) within the smtp server seems more appropriate rather than tacking records into dns entries.
DNS seems imho to be being overloaded with various add ons atm. If we're not carefull DNS will become the new bottleneck on the internet.
SPF is a really bad idea (Score:2, Interesting)
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 (Score:3, Interesting)
This doesn't help much.... (Score:3, Interesting)
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...
Re:omg... (Score:1, Interesting)
9
Some early morning math, which may be incorrect for that reason, suggests that 500 billion emails over the course of a year averages out to ((500,000,000,000 / 365) / 86400) = about 16,000 emails per second! And that's just the spam. Isn't it generally accepted that running Google takes 1000+ servers? If so, is it that much of a stretch to think that running AOL's massive mail ops takes 2000+ servers? I wonder if Google gets 16,000 hits per second...
They apparently haven't included any of their dialup space in the SPF record (nor should they have). 9
--
Rate Naked People [fuckmeter.com] at FuckMeter! (Not work-safe..but click anyway, it's Friday!)
SPF && DYNDNS (Score:3, Interesting)
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.
Re:I publish SPF records (Score:1, Interesting)
Consider that with widespread challenge/response adoption, if a spammer were to send a million 3Xt3ND UR P3N15!!! spams using pbowers@pipindomain.com as the author being joe-jobbed, then you would be the lucky recipient of 950,000 challenges. As things stand now, you would only receive 100,000 bounces and 2,000 flames and complaints. The latter is much easier on the Internet, and much easier on you.
Put another way, methods of fighting spam which do not result in an overall substantial decrease in the amount of bandwidth that spam runs consume are pointless at best. Client side filtering also does not work for that reason.
Other problems with SPF (Score:5, Interesting)
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.
Re:Would someone explain this to a simpleton? (Score:3, Interesting)
Thank you, carry on.
Also stops phishing (Score:3, Interesting)
Re:Other problems with SPF (Score:3, Interesting)
Pay per email? Pay whom, precisely? The ISP? I've already paid them for my subscription. If that is included in a spammers account, their spam gets through. Pay the recipient? Why should I pay you to send you email that isn't spam? Would you give me the cash back? You say that SPF works against the way the internet works, well, the internet is a free-for-all, so why is paying per email NOT against the way the internet works?
PKI? If Computer A trusts Computer B, does that mean Computer B gets a high ranking? What if Computer A is a spammer? Computer C, which nobody knows, and therefore nobody trusts, how do they get email out to people? They may be the next Slashdot, or have something earth-shatteringly important to say. Are you going to reject their messages because nobody trusts them? If they spam, presumably they get a negative score. But what if someone who has an axe to grind says they've spammed when they haven't?
How do PKI/Pay-for deal with throwaway domains, or compromised machines?
What if a new spammer starts out by sending out useful stuff, thus getting a high Trusted ranking, then starts to spam from it? What if someone who is Trusted gets compromised? Trust also doesn't fix spam.
Just because SPF doesn't fix everything including terrorism and obesity, does that mean it shouldn't be implemented?
I think SPF is a good idea. You get email from aol.com, but aol says "never heard of them" - there's a good chance this will be spam. Therefore spammers stop spoofing aol and spoof someone else. They then get loads of bounces and implement SPF. And so on, and eventually spammers have nowhere left to hide. It won't fix spam overnight, but it will reduce, and eventually remove, places for spammers to hide. The wonderfully double-entendred CAN SPAM act proves we can't rely on politicians, so we need a technical solution.
So you can't validly spoof your own address. What's wrong with setting different From and Reply-To? (other than it not being implemented in mail clients. But that can easily be fixed.) From=my ISP, mail gets validated as not Spam. Reply-To=my work address, so I get to send work email from home. That's why we have distinct From and Reply-To, no?
So you have to ask your ISP if you want to run a mail server. Why exactly is that so difficult?
You say SPF increases traffic. How much traffic does SPAM need to be before it becomes a problem? 5%? 10%? Some estimates place Spam at OVER FIFTY PERCENT OF ALL EMAIL. Clearly if the Spam traffic is not a problem at over 50%, the odd little bit of SPF validation traffic isn't going to make much difference.
SPF can reduce the amount of clutter on the network. It doesn't just have to be implemented at the terminal ISP. Clearly if an interim computer getting email bound for ISP X notices that SPF fails, it can drop or bounce the email instead of passing it on. Yes, this takes some CPU time. So does propagating Spam - even that isn't free. Besides, how expensive is CPU time these days? Do mail forwarders really use 100% CPU time or are they IO bound (I don't know the answer to this, so perhaps they really are CPU bound, in which case this paragraph is complete 130110x.)
Re:How about dynamic IPs? (Score:3, Interesting)
I hate it when people think stuff is so black and white.
Re:Tag it (Score:2, Interesting)
How about using the proper tag,
This is a good idea. I would recommend using the <a title="Sender Permitted From" href="link">SPF</a> method due to IE's lack of standards compliancy.
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.
Re:I see a problem here.... (Score:3, Interesting)
1. Make the customers use Webmail or equivalent when traveling. The mail still originates with your servers.
2. Make the customers VPN to your domain when traveling. The mail is then handled by your servers.
AOL basically does the second, if you connect to them via another service (like AOL High Speed stuff).
I know neither of those are as convenient as "free mail, anywhere, anytime, no questions asked", but that system is too open to abuse.
SPF Bad for POBOX's users (Score:3, Interesting)
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...
Re:I see a problem here.... (Score:4, Interesting)
As far as I can understand, your argument boils down to "I don't like SPF because my systems are hideously insecure, I'm cool with them being used as open relays, and I don't feel like being a competent sysadmin"?
That's what SASL is for (Score:3, Interesting)
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."
Re:Some of the benefits. (Score:3, Interesting)
In fact, it makes me wonder if they had a reason to decide against it.