Protocol-Level Spam Control #1: Introduction

We've been on record for some time as liking spam control defenses that operate at the protocol level -- IP, TCP, and/or SMTP -- as opposed to those that operate solely by analyzing message content. This is the first of a series of bulletins that talks more about this, and examines two technologies that implement such controls.

One important reason we like such protocol-level defenses is that rejections or timeouts at the protocol level will result in a Non-Delivery Report (NDR) being returned to a valid sender by a noncompromised sending MTA. This NDR allows the sender of a false positive to take remedial action.

When spam is rejected at the content level, receiving MTAs face a dilemma. Since the SMTP MAIL FROM address specified by a spammer is almost always spoofed, they are loath to generate NDRs -- or at least they should be. This, in turn, means that the sender of a false positive will not be informed that their message has been rejected. The rejection is silent.

Another way to state this is that a rejection or timeout isn't the same as a bounce:

  • In a rejection or timeout, the receiving MTA never accepts the message, so any NDR is generated by the sending MTA.
  • In a bounce, the receiving MTA accepts the message and then generates an NDR -- which in this case would likely go to an innocent third party. Such backscatter is as bad a problem as the spam itself.

It's also worth pointing out that recipients rarely go looking for false positives in their spam quarantines, so it's a useful thing if an NDR makes the sender aware of a false positive.

One of the first devices to operate at the protocol level was the Symantec Mail Security 8160 appliance -– previously the TurnTide "Spam Squelcher." It operates as an IP packet-level firewall/router interposed between the Internet and an organization's boundary SMTP MTAs.

MailChannels' Traffic Control represents another approach to anti-spam defense at the protocol level. It differs from the 8160 both in being Unix (Linux, BSD, Solaris) software (as opposed to an appliance) based solution, and in operating at the SMTP (as opposed to the IP packet) level. As such, it constitutes "another way to skin a cat."

In the next few bulletins, we'll compare the 8160 appliance with Traffic Control, calling out the operational differences.

... Nick Shelness and Richi Jennings

Post a comment

You must be logged in to post a comment. To comment, first join our community.