Home / Blogs

There Is No “Spam Problem”

This month I thought I could feel smug, deploying Postfix, with greylisting (Postgrey), and the Spamhaus block list (SBL-XBL) has reduced the volume of unsolicited bulk commercial email one of our servers was delivering to our clients by 98.99%.

Alas greylisting is a flawed remedy, it merely requires the spambots to act more like email servers and it will fail, and eventually they will. Greylisting may scale to big email servers, but it doesn’t scale to a lot of the population using it.

Designing and deploying a new email system requires one to spend time thinking about the types of abuse, and how best to address it. I chose greylisting, and block lists, as the resulting false positives tend to be revealed promptly, these methods don’t require end user interaction, and there are no “spam folders” where misclassified emails go quietly unread. Just don’t everyone start using it, please.

The Megaphone

The email problem we suffer currently is due to a small number of spammers, and a very large number of machines that are compromised and made to do the bidding of the spammers. Think small number of people, with a mighty large “megaphone”.

The problem is the “megaphone”.

Any solution to the supposed “spam problem” that doesn’t deal with the large number of compromised boxes will at best move the problem elsewhere. If we all deploy effective antispam measures without dealing with the megaphone, we can enjoy spam free email, but don’t be surprised when your website suffers a distributed denial of service attack, or your preferred instance messaging, or VOIP service, is full of spam.

Think Clearer

How does this help us? Well we should use this to allow us to focus on the solutions that address the underlying problem. Consider this informal response to “Operation Spam Zombies” from a man with more than a little experience of the ISP business:

Link to Google Groups

I’m sure the author wouldn’t claim it to be a deeply thought out response, but he immediately splits the proposals between those that address the underlying problem, and those that just make the clients email problem worse by making email harder to use legitimately.

When AOL Sneezes

When AOL attempted to suppress spam by blocking outgoing SYN packets to port 25, they got some good press, but PCs in their network were still responsible for a large amount of the email spam arriving here. The reason, the spammers were spoofing the SYN packet, and modified the zombies to start spamming when the acknowledgement was received, and were thus able to revive that part of the megaphone that AOLs actions had intended to deny to them.

Some of those PCs are probably still running rogue software, they just aren’t sending email (since AOL promptly closed that loophole). No doubt the criminals who control them have found other ways to make money out of them, let us hope it doesn’t involve keyloggers and bank account details.

I don’t mean to single out AOL, they came to my attention because they are bigger than everyone else, so even small issues with their system can feel like a torrent if it is directed your way. They have certainly done a lot to address the issues of spam both going into, and out of, their networks.

Those in the industry know where the real rogue ISPs are, let me merely put some perspective ny noting that a certain Korean ISPs network attempts to send us more email purporting to come from AOL, than AOL do.

Conclusions

Consider all antispam proposals in the light of the underlying security problem. You may use your resources more wisely, and the solutions will work better.

Don’t focus overly narrowly on email, it really isn’t the problem. Where an email “fix” is required consider a cheap tactical fix like “greylisting” to allow people to concentrate on the core problem.

I feel less smug now.

One of the basic tenets of both war, and security, is that it is almost impossible to defend against an opponent with far greater resources, we have to deny those resources to our opponents, before we can hope to win the war.

By Simon Waters, Consultant

Filed Under

Comments

David MacQuigg  –  Jun 22, 2005 6:50 PM

> When AOL attempted to suppress spam by blocking outgoing SYN
> packets to port 25, they got some good press, but PCs in their
> network were still responsible for a large amount of the email
> spam arriving here.

This is not consistent with what others have said http://www.circleid.com/article/917_0_1_0_C/, and what I have been able to learn about the actual numbers.  Based on a small sample of SpamCop reports, it looks to me like AOL has 100 times less outgoing spam than other domains. http://purl.net/macquigg/email/DomainRatings.htm

I sure wish someone would do a real study with a larger number of reports so we could finally put this question to rest.

Simon Waters  –  Jun 23, 2005 7:20 PM

Hi David,

the AOL outgoing spam I refer to is in a thread on Spam-L archive if you need details.

It was in response to the claims by Carl that AOL had stopped their spam problem. At the time I believe 15% of our incoming connections for which a TCP handshake was completed still came from AOL address space.

It was fixed shortly after, and AOL do now generate far less SMTP spam for their size now than other ISPs.

David MacQuigg  –  Jun 24, 2005 1:29 PM

Hi Simon,  Thanks for the clarification.
One more question.  Do I understand that what you are saying is AOL blocked only the initial SYN packet on port 25, but the zombies could just ignore the lack of an ACK response and continue the session?  This doesn’t make sense to me, but in any case, it seems the easiest and most effective thing to do is block all outgoing packets to port 25, except for a small number of IP addresses that have been granted permission to use this port.

Simon Waters  –  Jun 24, 2005 5:41 PM

It is my impression AOL did start blocking just SYN packets.

It is probably more complex, as certainly in the UK AOL try to proxy some outgoing email connections. So I assume they probably redirected the SYN or other strange behaviour.

However it was done in the UK, it was not reliably catching 100% of outgoing connections at one point as this confused both us and one of our clients when we tried allowing his IP to relay through our mail server. Or possibly it was being filtered in some other way.

I haven’t seen technical details of how AOL intercept SMTP packets, the comment on it being SYN packets (at least at first) came from an AOL staff member, although I don’t know if he was privvy to the specifics.

My point was that the underlying compromised boxes were still there and operated by spammers, even when the SMTP spam was absent. Independent of the mechanics of AOLs filtering.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

Cybersecurity

Sponsored byVerisign

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

DNS

Sponsored byDNIB.com

Threat Intelligence

Sponsored byWhoisXML API