Home / Blogs

What is Anti-Spam?

There's a lot of argument as to which "anti-spam" techniques are legitimately so called. In this article, I'd like to consider what constitutes an anti-spam technique in an ideal sense, then consider the various practiced approaches to spam mitigation in that light, drawing conclusions as to how we should frame the "anti-spam" discussion.

Classifying Spam

For the purposes of this discussion, let "spam" refer to "unsolicited bulk email". Not everyone agrees on this definition, but it's by far the most widely accepted, and without a working definition we won't be able to define "anti-spam". Thus, an email message is spam (for our present purposes) if it meets two criteria [ref: Spamhaus Technical Definition of Spam].

1. Bulk: the recipient's personal identity and context are irrelevant because the message is equally applicable to many other potential recipients.

2. Unsolicited: the recipient has not verifiably granted deliberate, explicit, and still-revocable permission for it to be sent.

It's important to note that both these criteria must hold for a message to be spam. Many legitimate and wanted mailing lists are "bulk" in nature, and some personal communications are not explicitly requested but desired nonetheless. Point number two does not have to hold for every single recipient: the message is spam in those instances where both points hold, and not otherwise. It follows that the exact same message can be spam for one person, and not for another.

The criteria are not highly precise. In point number one, the question of personal relevance has disputable edge cases. In point two, there may be a question as to whether a particular message was covered by the terms of the permission. From this latter observation, it follows that simple whitelists or subscriptions aren't entirely sufficient for expressing bulk mail requests: a recipient may request bulk mail on a particular subject, for example, and justifiably consider messages spam when they stray from that subject. The question as to whether a particular message is on a particular subject also has disputable edge cases.

This lack of precision doesn't prevent us (as human beings) from determining with some confidence whether an item is spam or not. The impersonal (or incorrectly personal) nature of bulk mail usually makes it obvious when point one holds. We can simply ask the question, "is this message personally relevant to me?" Point two is a judgment easily made from knowledge of what we have and have not requested, although disputed edge cases may require arbitration to resolve.

The criteria don't reduce to simple, mechanically-detectable conditions, however. Particularly large email providers can get a genuine idea of bulk delivery (which implies condition one) by comparing incoming messages across accounts, although this technique can be hampered by messages salted with random elements. Permission can only be expressed in its most explicit form — a whitelist — and the terms of permission can't be anything nuanced. Unsolicited messages can be detected at "spamtrap" addresses (which solicit nothing), but we can only surmise that other recipients of the same message did not request it.

Theoretically Ideal Anti-Spam

An ideal anti-spam system rejects messages which are both bulk and unsolicited, letting pass those messages which are of specific personal relevance to the recipient (not "bulk"), and those which the recipient has expressly requested (not "unsolicited"). When phrased in these terms, spam filtering is obviously a task for a well-informed intelligent agent of immense sophistication — quite beyond our current ability to construct. Anything less is a weak approximation at best.

The system described so far is ideal in the sense that it keeps spam out of a recipient's inbox, but it says nothing of network and computing resources consumed in the process. A system that accepts all mail and then discards the portion which is spam wastes significant resources on mail that will ultimately be discarded. This is the hidden cost of spam, and it can be arbitrarily large, since it depends on how much spam other parties send to the recipient. An ideal system must address this cost: it must not only be perfectly accurate, but also perfectly efficient. In the ideal case, each incoming spam is rejected at no cost to the recipient. Only under these conditions is the system guaranteed to scale under increasing spam load.

To address this, the hypothetical intelligent agent could operate at the sender's system, preventing unwanted data from entering the network at all. Unfortunately this seems practically untenable for several obvious reasons, not the least of which is the cost of replicating the agent at every prospective sender. But in order for the agent to operate from the recipient's system without the waste inherent in the "accept then drop" approach, it would need to engage with each potential sender in a very light-weight protocol for determining whether a candidate message is personally relevant or requested, prior to accepting the actual text. I can't even imagine how a protocol would meet these requirements, let alone be reliable in the face of a hostile sender. The situation seems intractable.

If an ideal anti-spam system is technically possible at all, it's firmly in the realm of science fiction for now.


By sheer necessity then, real "anti-spam" systems are weak approximations of the ideal, and as such they do not have to work by detecting the two key properties of spam: "bulkness" and "unsolicitedness". Any technique that has approximately the right outcome can be considered. However, if we are going to settle on something less than perfection, we need to make compromises, and not everyone is going to be satisfied with the same set of compromises.

There are those who believe that any measure for stopping spam should have as its first goal, "allow and assist every non-spam message to reach its recipients," [ref: Verio censored John Gilmore's email] with the implied corollary that any technique which might block a non-spam message is unacceptable — damnable "censorship", even. At the other extreme, there are those who believe that the only cure for spam is to banish spammers from the Internet, and that the effective means to this end is to threaten spammer-friendly networks with excommunication — and impose it where necessary, collateral damage notwithstanding.

These are ideological extremes, and never the twain shall meet. It's important to recognise when an argument about anti-spam has made the transition from being an argument over technique to an argument over ideology. Technique can be discussed in a more or less scientific manner, using metrics like false positives and negatives, cost of computation, network bandwidth consumed, and so on. Ideological differences have no such metrics, and need to be debated separately lest they prevent any kind of agreement being reached anywhere.

Most players lie somewhere in between these ideological extremes. As such, they grudgingly adopt a certain ratio of false positives to negatives as "acceptable", recognising that too much spam (by way of false negatives) can result in the loss of wanted mail anyhow. Everyone attempts to minimise both counts, but the acceptable ratio between the two will vary according to taste and need.

Some of the actual techniques used will now be considered.

Text Analysis

Text analysis judges whether the message is spam purely on the basis of its content. It depends on spam occupying a sufficiently distinct text-space from non-spam. Unlike a human judgement as to whether a message is "bulk", this approach does not generally involve any understanding of the message content, just statistical analysis of the text. The accuracy of this method varies widely depending on the algorithm used and the characteristics of the incoming mail. It can be quite effective, but would be a poor choice for an "abuse" address which is supposed to accept spam complaints.

A variation on statistical analysis is the detection of very particular features in the message which are believed to be unique to (or at least strongly characteristic of) spam. This examines specific individual traits, as opposed to detecting an overall pattern characteristic of spam. When spammers become aware of such tests, it is generally easy for them to side-step them, but the approach can be highly effective in the short term, especially in the heat of a virus outbreak.

All methods involving text analysis operate at the recipient's system after receipt of the message text. As such, they do nothing to address the hidden cost of spam, and any processing effort expended in evaluating the message adds to that hidden cost. Any "bounce" message generated as a result of rejecting the message at this late stage amplifies the cost further, and will probably constitute additional spam if the source address was forged. Filing suspected spam in a separate folder avoids some of the costs (and the possibility of generating more spam), but usually results in delayed and/or less reliable discovery of false positives relative to bouncing the message.

Source Address Blacklisting

Source address blacklisting is an aggressive approach which refuses all mail from sources which have a known bad history of sending spam, a bad reputation for the same, or some other feature which warrants blacklisting as a bad risk. There are also other applications for general lists of IP addresses, but refusing delivery of mail before "DATA" in SMTP is the application I wish to discuss here. Many sites maintain private lists of addresses which are no longer welcome, but the better known (and more controversial) instances of blacklisting involve publication in the domain name system.

The accuracy of the approach depends entirely on the portion of spam in the email emitted by the blacklisted site. If a site emits nothing but spam, then the technique is perfect, but this is rarely the case. Unlike most anti-spam techniques, blacklisting reduces the hidden cost of spam by preventing transmission of the message. False positives (and true positives, for that matter) are brought to the attention of the sender as non-delivery notices if the sender's systems are standards compliant. As all mail is refused, there can be no such thing as a false negative.

But to view blacklisting as a purely technical anti-spam strategy is to miss an important point: the potential social impact of public blacklists. Public blacklists do not have any effect in and of themselves: they are merely published lists of addresses. It is how people use these addresses which generates the impact. If a blacklist publishes the addresses of networks that do not meet certain standards of behaviour, and many people use this blacklist to selectively permit incoming mail, most network operators will be faced with a choice: conform to the standards, or suffer reduced email connectivity. Thus, blacklists are a means of applying peer pressure between independently operated networks.

The full impact of source address blacklisting as an anti-spam technique can only be appreciated in this light. The social pressure it brings to bear encourages many major players to keep their acts clean, and all mail recipients therefore enjoy some benefits of blacklisting whether they use it or not. Without it, many networks might welcome spammers as high-use customers; as it stands, many email service providers are good actors, taking reasonable measures to ensure that their networks are not spam sources, and the threat of blacklisting is what motivates most of them to expend this effort.

Other Techniques

Whitelisting is effective as an anti-spam technique, but it is overkill. It eliminates all sources which are not pre-approved, and so long as all the approved sources can be trusted to operate within the bounds of acceptable behaviour, it eliminates spam. It also eliminates any possibility of using the email address in question as a means of introduction. In the absence of a sender identification system, there exists the possibility that a spammer can circumvent a whitelist by forging a whitelisted address, but the spammer would have to obtain information about individual whitelists in order to exploit this loophole. Whitelists can be implemented such that they address the hidden cost of spam, given certain constraints on design.

Greylisting eliminates those senders which attempt delivery in a "hit and run" manner, not reattempting delivery in accordance with standards. This has nothing to do with the characteristics of spam in a direct sense, but it so happens that many spammers use "ratware" delivery systems which are egregiously non-compliant with regards to standards, and this technique efficiently prevents communication of messages from such systems. It also introduces a delay in which other data (such as blacklist entries) may become available, and this is the only long-term benefit of the approach if spammers fix up their standards compliance. It can also cause legitimate mail to be delayed, of course. Delaying (or preventing) delivery in this manner is relatively light on resource usage.

Sender identification systems such as SPF, DKIM, and many others attempt to create a verifiable association between an email and some domain name. Once again, this has nothing to do with the direct characteristics of spam, and the presence of a verifiable sender identity says nothing about whether the message is spam or not. Even so, a certified sender identity offers one more datum on which to blacklist or whitelist messages, and can mitigate some of the problems associated with other activities. Known identities can, in this manner, be given specific treatment without risk of misapplication. For example, known good actors can be exempted from filtering without risk of admitting bad actors with false identity. Spammers frequently make false identity claims, but they can stop lying (and keep spamming) if so obliged.

Challenge/response, in its broadest sense, attempts to determine that some source address of the message is monitored by a human being capable of taking some requested action. This effectively precludes the possibility that the message is sent in bulk, in most cases. There usually exists the possibility that the challenge message itself will constitute spam, since the address to which the challenge is sent may be a third party who has not expressly requested the challenge, and challenges qualify as "bulk" under our definition — and can be sent in arbitrarily large quantities to boot. The transmission of this extra data generally means that such systems increase the hidden cost of spam. They also create extra work for the recipient of the challenge as a matter of course, whether that challenge constitutes spam or not.


It seems that an ideal anti-spam system is a practical impossibility, given our working definition of "spam". Every practical approach we have to the problem attacks it obliquely, rather than directly. I would therefore encourage a liberal view of what counts as an "anti-spam" system. It is shallow criticism to say of a certain approach that "it is not an anti-spam system" when all this means is, "it has no immediate impact on the state of my inbox". The state of individual inboxes is merely the most obvious part of the problem.

Indeed, rather than frame the discussion as "anti-spam", I suggest we consider the broader picture of "email systems and their properties, particularly in relation to hostile or abusive participants". In this light, for example, sender identification systems can be seen as a means to prevent senders from making false identity claims, whereas they are seen as largely irrelevant when the discussion is "anti-spam". A system capable of sender identification has clear benefits over one that does not. Should we ignore these benefits simply because they don't relate directly to spam prevention?

Spam is a symptom — a symptom of a sick society, ultimately — and email systems can mitigate or exacerbate the symptoms, depending on their properties, but never fix the root cause. Thus, in the end, all we can ask of an email system is that it mitigate the harm caused by spammers and other miscreants as much as possible. In considering any approach to email, we ought to judge it on its own particular benefits and costs in this regard. The benefits aren't limited to "a cleaner inbox": they may consist in generally reduced costs to recipients, the ability to offer preferential treatment to good actors, the social clout to ostracise spammers, and so on.

Let's learn to appreciate the hidden costs and benefits of these techniques, and to think outside the inbox.

By The Famous Brett Watson

Related topics: Censorship, DNS, Email, Spam

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


Re: What is Anti-Spam? Hector Santos  –  Mar 05, 2006 2:20 AM PDT


I'm surprise no one added comments. Usually everyone has an "opinion" when it comes to spam. But maybe it is a tired subject already.

Nonetheless, I will provide my opinion.

To think out of the box, you must first get everyone in the box.

The basic overall problem with resolving the "spam problem" is that we have not updated the core SMTP process in 20+ years!  We are just adding "kludges" and inconsistent layers which explains why there are multiple methods, yet no universal and common method acceptable by all.

In my opinion, we need a mind set change in the "necessary folks", those who have a strong voice in molding the process since day one.  I might be bold to suggest, they need to retire and pass the torch to the next generation engineers.  The irony is that many of these folks are directly or indirectly associated with the "spam problems" we are trying to address.  So there is a vested interest in not having a 100% strong commitment to solving the problem at the core level and any attempt to do so is militantly resisted.  A preaching of "backward compatibility" is made, yet, these same people are advocating new designs that will required SMTP change.  They don't see it because they are not SMTP vendors.  We are an SMTP vendor. We see the proposals and the SMTP change requirements.  So lets just do it right once and for all.

The industry has been ready and primed for the 2nd coming and revamping of the telecomputing email communications system.  The first revamp during the late 80s/early 90s consolidated all the early proprietary systems to use the internet email system.  If we don't get a widely adopted solution to the problem, I'm afraid we will begin, if not already, to move towards proprietary and/or exclusive, and closed solutions isolated to certain larges groups only.

A "cost system" will most certainly begin a separation concept.  As a long time developer and producer of electronic mail/hosting products and solutions, there is no doubt in my mind it will further separate classifications of email users.

Of course, the question is, is this good?  Is this desirable.  Maybe it would be, maybe it won't. That all depends on how those businesses moving in this direction structure their operations.  I think it goes without saying that many see it as a new business model for profit, with an idealistic and more likely unrealistic perception it will reduce the problem.  How much will be the non-payee be at a disadvantage versus those that pay the extra cost?  Which also begs the rhetorical question if spam is a concern anymore for these businesses?  As long as the direct market pays the extra the cost of getting access to the the user inbox, the idea is that they have a higher priority now. Not lower.

Wat about the legalities?  What if a direct market is not getting his money worth?  What if the USER still says "BLOCK" this mail even if the marketer is paying the fees to the ESP/ISP?  Will the user have the option?  Will they have a choice?  Will the spam be wrapped instead as part of the EMAIL presentation and not actually part of the body? i.e, like GMAIL.

In the end, I believe what most people want is to reduce the malicious abuse at all levels, the system level and at the user level.

This can only happen, in my view, by taking a step back into the balcony and revisiting SMTP.  A great majority of the problem is NOT having the all actors to get "inside the box." By far, by industry measures, at least 80% or more of the "bad actors" are simply not 100% SMTP compliant.  Any SMTP vendor who has approached the problem, like Santronics has, by going back to SMTP basic, has realized an equal amount of the reduction in malicious abuse.

Once you enforce SMTP compliancy, then you can begin to talk about everything else. Whether it is wrapping it with a certification concept, trust layer or cost, it will still have the same problems if the compliancy issue is not addressed.

Hector Santos, CTO
Santronics Software, Inc.

The basic overall problem with resolving the António Pais  –  Apr 11, 2016 7:17 AM PDT

The basic overall problem with resolving the "spam problem" is that we have not updated the core SMTP process in 20+ years!

Now, passed 40 years, are world prepared to discuss better this issues?
Are still people here who want talk about new proposals?
I am working on it. Are you?
I am interested to bring back a new model. The world was changed. Technology too. Technics remains the same. A new aproach is needed.
Please, note, i am not interested to create a new protocols.

Re: What is Anti-Spam? Simon Waters  –  Oct 18, 2006 7:11 PM PDT

Clear definitions are for people who want lines where none really exist.

One could envisage a weak approximation to a perfect spam system that still produced the desired outcome for all the emails a particular person received. i.e. that a perfect system can't exist in theory doesn't prevent a practical system attaining perfect results in a larger number of cases. Just as a chess computer can't yet play perfect chess, doesn't stop them beating the worlds best humans.

All that is needed is a classifier system that is recognisably better than the person whose email is being filter. Once you attain that level, I suspect the human will be accepting of the odd error. Although humans are very slow to recognise when the machines are better than them at something, animal pride.

Re: What is Anti-Spam? Suresh Ramasubramanian  –  Oct 18, 2006 11:03 PM PDT

Hector, for a lot of proposed antispam solutions, particularly those that argue that smtp must be replaced, I'd strongly encourage the proposers to read http://www.rhyolite.com/anti-spam/you-might-be.html

I've had my share of words with the EFF on their standpoint on spam filtering (a quick google search http://www.google.com/search?q=suresh+ramasubramanian+eff should give you plenty of material on this question, a lot of which could be repeated in any comment I'd make to Simon's quite interesting article ..)

Proposals. António Pais  –  Apr 11, 2016 7:51 AM PDT

Please, I wish you could answer these questions:
What are the entities that we can make proposals?
What are the requirements for submitting proposals?

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Promoted Post

Boston Ivy Gets Competitive With Its TLDs, Offers Registrars New Wholesale Pricing

With a mission to make its top-level domains available to the broadest market possible, Boston Ivy has permanently reduced its registration, renewal and transfer prices for .Broker, .Forex, .Markets and .Trading. more»

Industry Updates – Sponsored Posts

Global Domain Name Registrations Reach 329.3 Million, 2.3 Million Growth in Last Quarter of 2016

Neustar to be Acquired by Private Investment Group Led by Golden Gate Capital

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Don't Gamble With Your DNS

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

How Savvy DDoS Attackers Are Using DNSSEC Against Us

Radix Adds Dyn as a DNS Service Provider

Port25 Announces Release of PowerMTA V4.5r5

Dyn Partners with the Internet Systems Consortium to Host Global F-Root Nameservers

New Case Study: Jobtome.com Replaces 30 Postfix Servers with a Single PowerMTA

Is Your TLD Threat Mitigation Strategy up to Scratch?

Domain Management Handbook from MarkMonitor

An Update on Port25 and the Future of PowerMTA - One Year Later​

Encrypting Inbound and Outbound Email Connections with PowerMTA

What Holds Firms Back from Choosing Cloud-Based External DNS?

V12 Group Sustains Customer Satisfaction by Deploying PowerMTA for Launchpad Platform

PowerMTA Now Offers Scheduled Delivery Control

DKIM for ESPs: The Struggle of Living Up to the Ideal

Reactivation Campaign: Shared vs. Dedicated IPs

Sponsored Topics