(e)Mail Insecurity

A further look at Todd Marshall's spam proposal

I read an interesting article on ZDNet today, a proposal ("Spam: leave it to the sender") by Todd Marshall on just what we need to do to fight spam. As soon as I read it, I knew that it would generate a bit of controversy.

The heart of Todd's proposal is simple: change the core e-mail transport strategy from push to pull. Todd suggests that SMTP has two characteristics that have left it vulnerable to spam:

1. Sender identity cannot be easily verified; it's too easy for a spammer to appear to be someone else. Although there are plenty of add-ons and proposals to combat this, there's no universally accepted solution for this problem.
2. SMTP is store-and-forward. Since messages travel along and up being stored on the recipient's server, Todd argues that this multiplies the cost for the recipient.

Todd's suggestion is instead to keep the message stored on the sender's server, which sends notification to the recipient that mail is waiting there. The recipient then reviews their inbox, selects the messages to receive, and the mail server kicks into action to actually retrieve those message bodies. In effect, Todd suggests making e-mail work in a way much like the way many NNTP clients work.

He argues that it provides the following benefits:

• It removes spoofing and anonymity (at least on the network level). If they spoof their address, you can't get the message anyway.
• It reduces message traffic and storage requirements. Only a small fraction of people will choose to retrieve the spam.
• The cost goes up for the spammer.

It's an intriguing notion -- but will it work? (Go read the article now before you continue.)

I don't really think so, and here's why:

1. Todd suggests that the client contacts the sending server to retrieve the message directly. Ouch! His model proposes direct contact between an untrusted foreign machine and each desktop in the organization. What a great way for viruses and trojans to spread! Even if you're generous and modify his plan so that the recipient's mail server retrieves the message and scans it before passing it along to the client, see the next point.
2. I think Todd forgets one of the major benefits provided by the current SMTP store-and-forward model: recipient aggregation. If I'm sending an e-mail to 100 users in your organization, I only have to physically transmit one copy of the message; that envelope of that copy lists all 100 recipients. Under Todd's model, each recipient only receives the message after approving it -- each opening a new connection to pull that message down. This provides *no* savings in the case of spam messages, because all it takes one recipient to have their blocklists improperly configured or to mis-click, and wham! the message is transferred. And that's the best case scenario that assumes that the recipient's mail server will be retrieving the messages and then storing the message for the other recipients in the organization.
3. Users already complain about perceptions of delays in e-mail delivery, despite SMTP not being designed for near instantaneous message transmission. In reality, this scheme is only going to make this perception worse, no matter which way it's developed. The technical headache of trying to replace SMTP with this new Usenet-like protocol will be lost in the blinding migraine of trying to change the massed expectations of e-mail user culture. E-mail is a critical application for most organizations that have it, and they already spend a lot of time and money to make it work faster. They aren't going to want any measures that slow it down.
4. I already mentioned to incredible headache of trying to get SMTP replaced. I think the sagas of SOAP and MARID show us that the days of gradual replacement of mainstream protocols is long-gone. Heck, look at how many organizations still run software that fails compliance with RFC 2822.
5. Todd again forgets that the efforts of ad hoc anti-spam groups like SPEWS are already having a large effect on spam. Spammers are running out of ISPs they can openly run from without being blocklisted off the face of the 'Net. They're having to work with virus and trojan writers, break the law by exploiting open relays and proxies, and generally behave in violently anti-social ways in order to get their messages through. The vast majority of spam these days doesn't originate from SMTP servers; it is relayed through zombie networks of hacked machines. Legal actions by companies with large pocket books are going after the biggest spammers. I've seen data suggesting that the relative numbers of spammers is smaller than ever, even as they're desperately jacking up their output to combat anti-spam measures in order to maintain their profitability.

So if Todd's idea isn't the answer, what is?

Frankly, there isn't one. There's no easy answer to spam. There are many actions we can take:

• Ensure that we have correct forward and reverse DNS. I can't count the number of places that still break this one.
• Be careful about our ISPs' abuse policies and enforcement. Make sure your ISP isn't helping spammers.
• Re-think our IP allocation policies, if we're an ISP. Intermingling static business customers in the same block with dynamic clients helps no one separate the wheat from the chaff.
• Pressure our network neighbors to clean up their trojans, worms, viruses, proxies, and relays. They are costing us time and money. If that pressure includes a boycott, even better, because money really does talk.
• Insist that your vendors implement standards as written and fix problems promptly. If they want to provide proprietary extensions or protocols, great -- as long as they are in addition to standard-compliant mode, come disabled by default, and gracefully degrade when communicating with a system that doesn't implement the same extensions.
• Roll out IPv6 already! At least there IP forgeries become a thing of the past.

Granted, most of my suggestions don't speak directly to SMTP, but that's okay; I don't think the underlying problems that cause spam are technical. I think, in the end, we are awash today in spam because our corporate culture finds it easier to foot the short-term costs of spam than to pay the long-term costs of following my suggestions above. Spam allows us to wallow in a victim mentality, secure in the belief that the costs are being inflicted on us by someone else.

That's a problem that no protocol or technical solution will fix.

Print | posted on Monday, October 11, 2004 9:15 PM