Spammers Are Early Adopters of SPF Standard

nazarijo writes "In an article entitled Spammers using sender authentication too, study says, Infoworld reports that a study by CipherTrust shows that SPF and Sender ID (SID) aren't nearly as effective as we expected them to be when combatting spam. The reason? Spammers are able to publish their own records, too. 'Spammers are now better than companies at reporting the source of their e-mail,' says Paul Judge, noted spam researcher and CipherTrust CTO. Combined with low adoption rates of either SID or SPF (31 of the Fortune 1000 according to CipherTrust), this means that the common dream of SPF or SID clearing up the spam problem wont be coming true. Wong, one of the original authors of SPF and a co-author of SID, says that it was never intended to combat all spam. Weng, another researcher in the space, says that this is just one of the many pieces of the puzzle needed to combat spam. Various SID implementations exist, including a new one from Sendmail.net based on their milter API, making it easy for you to adopt SID and try this for yourself."

Re:A Change Needs to be made

[pikine]

A more reasonable change would be SMTP-TLS, employing a policy of using authorized certificates like the secure websites. This protocol is already there, but it's the wide adoption that is the problem.

SPF is an anti-forgery tool, not an anti-spam tool

[cas2000]

SPF doesn't and can't block spam.

it has a different purpose. it prevents some email address forgeries. its main use is to allow a domain owner (e.g. an individual or an organisation or a corporation such as a bank) to specify exactly which hosts are allowed to send mail claiming to be from that domain.

in other words, it can be used to block forgeries such as phishing spams and viruses, but it is not a general purpose spam blocker.

it does that job reasonably well (or, it will when it is implemented by enough mail servers). to complain that it doesn't do a job it was never designed to do is just absurd.

Re:Understanding SPF

[moreati]

It'll cut down on problems where forged senders are the main symptom, dramatically. That both includes viruses ( virii ) and some spammers

And there in lies the wonderful synergy of SPF and blacklists. Without From address forging it becomes much to perform the follow sequence:
1. I received a Spam message from domainx.com, either:
(a) sender was a verified user of domainx.com, spf records check out
(b) no spf, sender likely forged
In case (a) inform the ISP of domainx.com, if further verified Spam messages are received from domainx.com, blacklist it.
In case (b) if SPF is in widespread use for ligitimate mail then the soam message is easier to mark as such (less need to resort to expensive statistics on the body). If SPF is not widespread there is less benefit.

Regards

Alex

Re:Understanding SPF

[Jane_Dozey]

But then the main symptom is probably going to change rather than go away.
Blocking one form of attack will most likely mean an increase in another, or a new one entirely.
I doubt very much that SPF will be an end to spam, even if it is widespread.
People need to be taking away the incentive for spammers to bother. Would _you_ send out millions of emails if you weren't going to make any money?
This is a social problem, not a technical one.

Re:SPF is an anti-forgery tool, not an anti-spam t

[joeljkp]

Wait, wait. SPF prevents you from sending an email from one domain with a different @domain.com?

I have a university e-mail address that ends with @msstate.edu. But I don't live on campus, I live in the surrounding town and so am not on the msstate.edu domain. My SMTP host is nctv.com.

Right now, I can just set up my mail client to use [e-mail] and send it through nctv.com. Will SPF prevent me from doing that and force me to use webmail or something equally inconvenient?

Re:Appearantly, some people missed the point...

[taustin]

Spammers already use automated systems to sign up for dozens of domain names at a time, using fake contact info. Nothing can be done about that, because the after life of a spam domain is less than the time it takes to detect the bogus contact info anyway. And the whole thing likely operates through a zombied proxy, making it impossible to track down the real point of origin. Add in a stolen credit card number (spammer would never do something criminal, would they?), and you have a system where adding in SPF records is one extra line of code to the section that adds in the other DNS records.

SPF will do nothing to stop, or even slow down, spam. And the more people who use SPF to whitelist, the more it will increase spam getting through.

Re:A Change Needs to be made

[T-Ranger]

If you are talking about using TLS to ensure authenticity of a source, then SPF does that (somewhat). If a message claims to be from domain X, and domain X uses SPF and already only allows messages from their servers, then that message is from domain X. TLS, as far as authenticity goes would add nothing. The only difference is that spammers would now also have to buy a TLS cert.

About the only attacks that TLS would pervent would be IP spoofing. These days, that is very, very hard.

What would TLS add?

The SPF faq on Throwaway domains.

[nlinecomputers]

From the SPF objections page at http://spf.pobox.com/objections.html

Throwaway Domains

(From John Levine:) Or spammers can register throwaway domains of their own, since burning an $8 domain for a 10 million message spam run isn't much of a deterrent.

Throwaway domains can be listed in sender blacklists which respond in real time to automated discovery methods.

SPF needs to work in hand with reputation schemes.

There are many possibilities. The reputation scheme most familiar to people is the DNSBL, which blacklists IP addresses. RHSBLs are the analogue for domain names. A number of them are listed at the bottom of Blacklists Compared.

% dnsip yahoo.com.spamdomains.blackholes.easynet.nl

% dnsip amazingoffersdirect.net.spamdomains.blackholes.eas ynet.nl
127.0.0.2
%

Greylisting is another approach. It is elegantly simple, but it has three disadvantages.

1. People don't like to have to wait for real mail. After a while your users will say, "why is mail from my mom always getting delayed by an hour?" and you'll have to whitelist all your users' moms.
2. You need to do custom whitelisting for entire domains, because Yahoo Groups does not respect transient failure errors --- it treats them as permanent.
3. It is trivial for spammers to get around greylisting, because spammers don't actually queue messages; everything's just an entry in a database. Spammers aren't stupid. They can just repeat the run. Until they figure this out, greylisting will work.

Some suggest that reputation schemes would eventually be a lot like credit rating agencies: they don't say "yes, approve this loan"; instead they tell you what an individual's credit risk is, and it's up to the bank to decide.

Similarly a reputation service would provide a spam vs total ratio: (numbers are made up)

domain: yahoo.com
born: 199501
total: 4.3E12 messages
spam: 1.2E3 messages
ratio: 2.8E-10

domain: superspammer.net
born: 200303
total: 6.3E7 messages
spam: 3.4E7 messages
ratio: 0.53

Of course those numbers would have to be based on SPF-verified domains. There would be three types of domains--- SPF, "best-guess-match", and non-SPF publishers. "Best-guess-match" means the domain would have passed SPF tests if it had declared "a mx ptr" mechanisms. But that's a small detail.

Any major ISP could track these stats pretty easily and build their own reputation system. Or non-ISP organizations like Cloudmark could too. I expect The Internet will come up with a good, free one that's built right into MTAs like Postfix and Sendmail.

The algo would work something like this:

If the sender domain is known to the reputation system, we can make the decision based on local policy. (Local to the domain, or even to the individual user.)

If we don't have a lot of data on the sender domain, (eg. maybe the domain hasn't been around very long) we can do greylisting for the first pass; if our reputation service has good response times, we can expect it to have an answer ready the second time the sender tries. Or we can accept the mail but content-filter it, then report the results to a reputation system.

Obviously we need to introduce expiry and all that other stuff, but that's the basic idea.

And it would become an accepted social standard that if your domain hasn't been on the Internet very long, you wouldn't expect your mail to get through to people right away.

There's lots of research going on in the reputation systems space. It doesn't seem to be a fundamentally hard problem.

Basically you end up only accepting mail from known trusted domains. If you are just starting a domain then your mail may be held up or even bounced by some users. Just as new car drivers get higher insurance so can new email domains have to pay in boun

Want to know what works? Look at who Spammers hate

[humankind]

If you want to know what method works, look at what Spammers are doing. Look at which systems (i.e. osirisoft, spamcop, spamhaus) the spammers are attacking. They are almost exclusively launching attacks at the relay blacklists. This is because this is the one method by which they are SHUT DOWN. Forget legislation. Forget all the other efforts. RBLs work. The next generation is to go from relay blacklisting, to relay-whitelisting.

Fixing SMTP is like Fixing Weather

[billstewart]

Lots of people rant about how "somebody" ought to redesign SMTP so it's "better", but it's mostly just talk from people who don't have sufficiently clearheaded ideas about how a mail system should be designed to actually do anything useful. Meanwhile, changes like SMTP-over-SSL are getting introduced and fit into SMTP just fine. And SPF seems to be a useful bandaid that fits nicely alongside, because SMTP and DNS were designed by tool-builders rather than monolith-builders like MSMail/Exchange/Outlook.

The biggest things I've seen that "somebody" needs to fix about SMTP and DNS are 8-bit cleanness, and unfortunately Verisigh's trying to add international domain names by radically breaking DNS for web-only use, and Unicode complicates the details of any character set support issues (not that that's a bad thing, it's just exposing the fact that the job is harder than it looks.)