Integration of anti-spam techniques into MTAs

From Wikipedia, the free encyclopedia

Many regular Mail Transfer Agents (MTAs) either do not have more than the basic anti-spam measures built into them, or have built-in anti-spam systems that may not be appropriate.

Integrating anti-spam techniques into the process of receiving a message means that the MTA receiving a message processes the message data in the background, passing it through any number of anti-spam measures, before deciding to accept or reject the message. Messages that are not classified as spam get accepted and delivered to the original recipient; messages classified as spam get rejected during the SMTP dialogue.

Contents

[edit] Advantages

Doing this avoids the following problems with conventional anti-spam filtering:

  • spam e-mails are never bounced, that is, they are not sent back to whoever is listed as the sender of the message creating "backscatter". Because many spam email messages arrive with forged headers, these bounce replies go to the wrong addresses and in turn end up spamming other innocent people whose addresses were forged by spammers. Instead, when anti-spam measures are integrated into the SMTP dialogue, the machine delivering the message is instantly told that the message is rejected, and nobody else receives any bounce messages.
  • spam e-mails are not stored, so they do not waste any disk space after being processed. This disk space saving can be very significant, especially if there are e-mail archiving requirements.
  • spammers are notified that their delivery attempt was unsuccessful, so they might stop (in theory they should drop those email addresses from their databases), rather than hammer the same email addresses over and over again with a conventional system.
  • when the anti-spam system classifies a message wrongly as spam, the legitimate user who sent it is immediately notified. With a conventional system which would quarantine or discard a message after accepting, they would have no idea what happened to their e-mail. This could result in users re-sending their email multiple times, or calling the recipient to ask whether they have received their email.

[edit] Disadvantages

Adding anti-spam functionality at the time of SMTP delivery means that:

  • The mail server software needs to have extra processing logic that quietly passes mails through anti-spam checks. In case of using proxies (as described below), that is inherently handled by another process which is usually on another machine, which in turn means an increased cost to acquire and maintain.
  • The server needs to be able to handle a large load - CPU-intensive and network-intensive anti-spam measures can delay mail delivery, and in case of higher incoming load, reckless repetitive invocations of such expensive procedures can make the machine grind to a halt. This problem is alleviated by using software with proper support for timeouts (giving up on an anti-spam measure that takes too long to complete) and resource control (giving up on running things that take too many system resources to complete). Nevertheless, anti-spam integration will generally expose a system to a denial-of-service attack, unless very carefully tuned.

[edit] Methods of anti-spam measure integration

[edit] Transparent SMTP Proxies

A transparent SMTP proxy can be used to add spam filtering without changing any already installed mail server. If one decides to switch to a different MTA, they can still use the same SMTP proxy. Many SMTP proxies have anti-spam features as a major design goal and are quite flexible.

[edit] MTA-specific integration

Modern MTAs generally support various anti-spam measures. In the open-source world, most popular SMTP servers support particular anti-spam measures such as stringent checks for RFC compliance, DNSBLs, greylisting, and many also support SpamAssassin integration.

Sendmail, and more recently Postfix, support the notion of Milters, which enable integration and scanning at SMTP time, although rejections are not necessarily handled gracefully. Postfix documentation refers to this as before-queue filtering. Exim supports in-session filtering through the local_scan API. ColdSpark's SparkEngine supports integrations with leading anti-spam vendors such as Postini, Symantec's Brightmail and others via their extensible API.

[edit] See also

[edit] References

 This article does not cite any references or sources. (July 2006)
Please help improve this article by adding citations to reliable sources. Unverifiable material may be challenged and removed.