Spam control: it’s all up to the recipient MTA

In the vast majority of cases, spam detection is carried out on the last MTA before the final recipient of the e-mail. This can pose considerable problems, and there are a number of ways in which we can lighten the load.

Most current anti-spam systems are based on a post-acceptance principle, i.e. the MTA(Mail Transfer Agent) receives messages and stores them in a queue before delivering them to recipients. This treatment entails a risk of delay and loss of legitimate emails in the event of heavy traffic, leading to system overload. It has to be said that the burden of spam detection falls almost entirely on the recipient. However, the vast majority of spam is sent by automated systems, usually zombie PCs.

If all ISPs, e-mail providers and corporate networks decided to monitor their outgoing e-mails to neutralize these zombies, the volume of spam in circulation would be considerably reduced. This would lighten the load on end MTAs (and therefore no longer lead to losses or delays in mail delivery), prevent entire domains from being blacklisted because one or a few zombies are massively spamming a few of their IPs, and even prevent a domain from getting bad press (who hasn’t heard the criticism of such and such an ISP or host that is incapable of neutralizing zombies present on its network and spraying the rest of the Internet?) Unfortunately, detecting and processing spam in messages on the sender MTA comes at a cost, in addition to the cost of detecting incoming spam. No organization or entity will engage in such a practice, especially as it is not the first victim of outgoing spam.

Solutions are therefore implemented to lighten the load on the recipient MTA and guarantee the quality of its service. These include assigning a differentiated processing priority to e-mails: legitimate e-mails are processed first, and spam is analyzed afterwards. This way, even under heavy load, legitimate e-mails are less likely to be lost or delayed. The disadvantage of this technique, however, is that it can only be applied after the mails have been received by the MTA, which does not reduce the total number of mails queued. The MTA has no choice but to accept all incoming messages with the same priority level, because it is unable to discriminate at this stage of the process.

Another possible technique is to use an MTA proxy to perform e-mail classification in the event of a heavy load, before the final MTA takes over distribution only. The burden is therefore essentially shifted to the MTA proxy, but the latter also has to fully receive/reconstitute e-mails before being able to analyze them.

A post-acceptance MTA proxy configuration is linked to the bounce management issues discussed in our article: user management and call-out. To overcome these difficulties and control the actions to be taken depending on the nature of the e-mails, we strongly recommend analysis during the transaction in the SMTP protocol (see article on analyzing spam in the SMTP protocol).