Support /
Knowledge Base

How Emails Travel

General Information

Email is, together with www, probably one of the most underrated services that form a company’s IT backbone. Still, a malfunction or total stoppage of this system may very well cripple an organization’s effort. A proliferation in recent years of virus and spam attacks rendered hundreds of networks unable to manage this threat, and a huge collection of tools have been devised to deal with these problems. A common inconvenience using all this software is the need to invest a lot of time and effort into learning, deploying, configuration and maintenance operations. Syneto’s email proxies aim at harnessing the power of filtering email traffic against spam, viruses and unwanted communication under a common interface, facile to learn and use.

However, the email communication system is complex, and someone using Syneto and its email proxies for the first time must have the ‘big picture’ in his mind. This document aspires to draw it, trying to unhide the following areas:

  • how Syneto’s email proxies should be integrated into a local network architecture
  • how emails travel through the proxies
  • where to look for answers when there are problems with email traffic (i.e. traffic does not arrive at destination, is not filtered or is too slow)

Given the the size of the topic and constraints on the length of this document, we won’t go into too much detail. Rather, we try to analyze the most common options we find in today’s networking environments.

Syneto’s email proxy system is comprised of three subsystems: SMTP proxy, POP3 proxy, and the scanning subsystem. As far as the proxies are concerned, their only mission is to intercept the traffic, deliver it to the scanning subsystem and, if the email must be stopped, they should take the appropriate actions. The decision job is left squarely on the shoulders of the scanning subsystem.

For maximum efficiency in stopping unwanted emails, we use a four pronged approach: the email filtering module, the bayesian antispam engine, the Clam antivirus and the IP Reputation system. In conjunction with these four active modules is the quarantine, a special place where are stored emails meeting the following conditions:

  • virused emails
  • emails for which an error occurred during scanning, ranging from too email too large to damaged emails that could not be processed emails sent on purpose to the quarantine using an email filter or using the Bayesian antispam engines

This paper will detail in the following pages how to configure and operate the five scanning modules and the quarantine.

The Proxies

This section is dedicated to detail the path taken by an email while traversing the email proxy system. It also contains some useful information that may help debugging email related problems. Because both proxies act upon the same data stream (emails) they share the same email scanning underpinning.

Both proxies forward information about the email to the scanning subsystem and expect to be notified about the results of the filtering/antispam/antivirus operation. Depending on the outcome, they will allow the email to pass or will take the appropriate measures: put the email in quarantine, mark it as spam etc.

To help debugging problems related to the email proxies, you can use the following logs:

  • mail.log to search for generic problems of SMTP and POP proxies and problems with the scanning subsystem
  • smtp_proxy.log – a listing of emails passing through the SMTP proxy
  • pop_proxy.log – a listing of emails passing through the POP proxy

The Path of an Email Through SMTP Proxy

Any communication on port 25 passing through appliance is automatically diverted to SMTP proxy using the local firewall’s port forwarding facilties. SMTP protocol commands are checked against a set of ‘hooks’ which spring in action even before the email is fully accepted into the system. This means that sometimes that a reject can occur even if the other part hasn’t sent a single byte of useful data. This is the case with greylisting, verify sender and verify receiver systems. Once the email has passed these ‘hooks’ and has been accepted into the proxy, it is registered and passed to the scanning subsystem. If the email is found to be malicious, it is discarded, put into quarantine or marked, depending on the configuration of the scanning module that caught it. If the email was granted a pass through, it is placed in a queue to be delivered to its original destination.

Figure 1. Path of an email through SMTP proxy

The Path of an Email Through POP Proxy

POP proxy uses the same mechanism of port forwarding to capture all the traffic on port 110 and divert it through it. Once the email has been accepted into the system, it follows much the same way as described above with the exception that, when the email is clean, it isn’t put into a queue but it is directly delivered to the client. To debug POP3 proxy operations, search mail.log for entries matching ‘POP-Proxy’. Emails entering POP3 proxy should appear in pop_proxy.log. To debug any problems with the scanning subsystem, search mail.log for entries matching ‘Scanner-Queue’ and ‘Email-Scanner’.