Home / Blogs

The Naive Arrogance of FUSSPs

John Levine

Everyone who's been in the e-mail biz long enough knows the term FUSSP, Final Ultimate Solution to the Spam Problem, as described in a checklist from Vern Schryver and a form response that's been floating around the net for a decade.

FUSSPs fall into two general categories, bad ideas that won't go away, and reasonable ideas that are oversold. The classic bad idea is e-postage, charging for e-mail. I wrote a white paper about it a decade ago, and nothing of importance has changed.

Reasonable ideas that are oversold are much more frustrating, and there are a lot of them in the e-mail authentication field. One of the bad ideas is that if we just knew who was sending every mail message, we'd have no spam, which is silly for many reasons.

It's not at all silly in weaker versions. There are plenty of partial authentication schemes that let us identify interesting parts of our mail stream so we can whitelist mail from some senders we know. Attempts to give an identity to each user, PGP and S/MIME, have never been widely adopted because it's too hard to distribute the keys into each user's mail program. Less ambitious schemes where the granularity is the domain name are quite workable for parts of the mail stream, but suffer when they're oversold.

A sure fire way to tell when an authentication scheme is turning into a FUSSP is when naive enthusiasts demand that other parts of the mail system that work perfectly well have to change what they do to deal with limitations of the authentication scheme. Invariably, the mail system keeps doing what it's always done, and people learn to live with the limitations of the authentication scheme, but teaching the enthusiasts to curb their enthusiasm is very frustrating.

About a decade ago, the new authentication scheme was SPF. For some kinds of mail, particularly bulk mail all sent from a known set of servers, it works quite well. For others, such as mail systems with human users who send mail in a variety of hard to predict ways, it works much less well. SPF has ways to deal with this limitation, by allowing various intermediate results between pass and fail, but by golly the enthusiasts wanted to fix the e-mail world so that all legitimate mail would pass. (Presumably they would reject all mail that didn't pass, and solve the spam problem.) To try to force the issue, some of them had their mail systems reject any mail that didn't pass, thereby losing lots of perfectly ordinary mail that didn't happen to be sent in a way that SPF can describe. Add-ons to SPF with names like SES were supposed to let the rest of us "upgrade" our mail systems so that forwarded mail, a particular sore point, could be SPF compliant, but in practice what happened was that people adjusted their SPF to avoid needless damage and the mail system works the same as always.

The next round was with DKIM. While SPF tries to validate the path a message takes, DKIM puts a cryptographic signature in the message. That doesn't depend on the path the message takes, so forwarding isn't usually a problem. For DKIM, the FUSSP issue arrives with mailing lists. Most mailing lists make small changes to the messages for the convenience of the list subscribers, such as adding a list tag to the subject line, or a message footer that says what the list is and how to subscribe or unsubscribe. If the incoming message has a DKIM signature, these changes invalidate it. The mail system running the list software can add its own DKIM signature, recipients use that signature to recognize list mail, and everything works.

Some DKIM enthusiasts insist that mailing lists need to preserve DKIM signatures from incoming mail by turning off the convenience features that break signatures, even though that would solve no problem whatsoever. (I can't wait to see the comments on that one.) List operators, of course, have ignored them, since the subject tags and message footers are useful, and lists work just fine as is.

This year's authentication hack is DMARC. It sits on top of DKIM and SPF and allows senders to describe their sending policies, and offer advice to quarantine or reject mail that doesn't match the policy. For domains like Paypal that are heavily forged and send all their mail from a small set of known hosts, DMARC is very useful to tell people how to detect forged mail. For domains like mine, who are forged only by the occasional random spammer who picks fake return addresses out of the spam lists, and whose mail goes through forwarders, mailing lists, newspaper send-to-a-friend, and so forth, DMARC has some interesting ways to gather statistics, but the policy parts are not useful.

Predictably, there are DMARC enthusiasts who want every message ever sent by anyone to have a "reject" policy, which will solve the spam problem by rejecting all spam. (Perhaps they are too young to remember the past two iterations.) This again brings us back to mailing lists. DMARC policy assertions can't describe list mail for the same reasons that list mail fails DKIM, and it doesn't matter for the same reason, receivers can recognize mail from lists their users subscribe to. But DMARC adds an extra level of excitement: overzealous use of DMARC by list contributors can make receivers reject valid list mail, which list software interprets as bad recipient addresses, and removes entirely valid subscribers from the list.

You will probably not be surprised to hear that the enthusiasts blame the problem on the mailing lists, which should turn off features that break DKIM signatures, or need to be rewritten with complicated heuristics to recognize and ignore DMARC bounces, or something, rather than the actual problem, which is that they're publishing the wrong policy. List software will of course not change what it does; at most it will recognize and reject incoming mail from subscribers that have strict DMARC policies. There are already patches to GNU mailman to do this, and I've found I can adjust my majordomo2 lists do to so with a one line configuration change.

I suppose it's nice to know that we're still getting new enthusiasts in the anti-spam biz, but it sure would be nice if they'd read the history before making the same mistakes over again.

By John Levine, Author, Consultant & Speaker. More blog posts from John Levine can also be read here.

Related topics: Email, Spam


Don't miss a thing – get the Weekly Wrap delivered to your inbox.


well said, brother Paul Vixie  –  Dec 27, 2013 6:08 PM PDT

i'm not arrogant enough to say "if it was that easy to stop spam, we'd've done it by now" but i do wish that newcomers to anti-spam would do some homework before making pronouncements. for example, see and .

well spoken, brother. amen.

The general theory Phillip Hallam-Baker  –  Dec 30, 2013 6:17 PM PDT

The behavior is much more general than just Spam.

Every security problem has a very simple solution, but only if that is the only problem you are going to solve. When the problem of the day is P, it is easy to see that it is solved by X but the fact that Q, R and S must also be solved at the same time is ignored.

The EFF went to some trouble to design their Sovereign Keys scheme that 'solves' the key management problem by assuming that network admins will never make a mistake and so the hard problem of key revocation will never need to be addressed.

People suggest peer to peer schemes to solve every problem in blissful ignorance of the fact that such schemes are regularly gamed on Amazon, yelp, etc.

And then there is the flip side of 'this can never work because of ' which is almost invariably some corner case that the speaker has no direct knowledge of. People keep telling me that content analysis is so important in spam control that end-to-end email encryption is completely non-viable. Now even if this was a concern, there are technical options. I don't have to accept end-to-end encrypted mail from unknown, unauthenticated senders. But I get the feeling that most of the people raising the objections have no experience in spam control beyond a vague idea of how the tools worked ten years ago.

Another variation of splunge is recourse to the mythical user from some third world country that only connects to the Internet through a 30 baud paper tape loop. Such users are invariably trotted out when someone suggests a modest change in Internet protocols like dropping support for obsolete protocols.

To post comments, please login or create an account.

Related Blogs

Related News

Explore Topics

Dig Deeper

DNS Security

Sponsored by Afilias

Mobile Internet

Sponsored by Afilias Mobile & Web Services


Sponsored by Verisign

IP Addressing

Sponsored by Avenue4 LLC

Promoted Posts

Buying or Selling IPv4 Addresses?

ACCELR/8 is a transformative IPv4 market solution developed by industry veterans Marc Lindsey and Janine Goodman that enables organizations buying or selling blocks as small as /20s to keep pace with the evolving demands of the market by applying processes that have delivered value for many of the largest market participants. more»

Industry Updates – Sponsored Posts

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Port25 Announces Release of PowerMTA V4.5r5

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

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

Encrypting Inbound and Outbound Email Connections with PowerMTA

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

To Where are Bounce Messages Sent?

An Open Source Perspective on Commercial MTAs

Five Essential PowerMTA Configuration Tips

What's New With Port25's PowerMTA v4.5

New Feature in PowerMTA v4.5: IP Based Rate Limiting

Case Study: Emergency Response Systems Rely on Timely Messaging Through PowerMTA

Port25 Announces Next Major Release of Its Email Delivery Solution, PowerMTA

Case Study: How PowerMTA Transparent Deliverability Metrics Paves Way for Email Service Provider

Case Study: MailChimp Achieves Efficient Execution and Reliability with PowerMTA

Case Study: Emma Swaps Its SMTP Infrastructure for PowerMTA to Handle Growing Mail Volume