Integration of anti-spam techniques into MTAs
From Wikipedia, the free encyclopedia
Regular Internet servers which run Mail Transfer Agents (MTAs) in order to operate SMTP do not generally have many anti-spam measures built into them.
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. 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.
- 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] Proxies
SMTP proxies are logically installed between the Internet and the actual SMTP server.
Depending on the implementation, the proxy can be either visible or transparent to the receiving MTA:
- When the proxy is transparent to the MTA, the MX records are kept intact and the MTA thinks it is receiving email from the Internet as it normally would.
- When the proxy is visible to the MTA, the MX records are modified to point to the proxy server address(es), which in turn passes them on to the actual MTA.
An advantage of SMTP proxies is that they work with any already installed mail server. If one decides to switch to a different MTA, they can still use the same SMTP proxy.
Certain SMTP proxies implement connection management, which ensures that no matter how big a spike in traffic coming from the outside (e.g. a virus outbreak or a DoS attack), the back-end mail server will not receive more connections than it can handle.
Some proxies can implement throttling - where suspect SMTP connections are slowed down. When slowed down, spammers typically give up (since they need to deliver huge volumes of email), whereas legitimate senders don't mind waiting a few minutes. This is a lenient version of tarpitting.
Throttling is hard to implement in a non-SMTP proxy solution, since each throttling connection holds up a usually heavy-weight process or thread, whereas a proxy can be implemented as a very efficient asynchronous I/O solution which can juggle thousands of connections at once.
[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.
