Epistula Mail Server: What it is and what it does

HadronZoo::Epistula (or simply Epistula) is an open source Linux C++ program which provides a web-configured, combined SMTP and webmail service, capable of supporting ~250 users on an entry level server. The mailserver is standard but the webmail service design borrows from online discussion forums, as it is geared towards whole conversation threads. Epistula is based on the HadronZoo class library, with which it is supplied as part of the HadronZoo download. Epistula, exactly as it is supplied in the download, is deployed as mailserver for the hadronzoo.com domain.

Email systems often use email addresses as usernames, implying a 1:1 relationship between user accounts and email addresses. Epistula can be configured likewise, but that isn't the idea. Epistula usernames are strings, and accounts can have multiple email addresses, each of which are specified as inbound, outbound, or full duplex. An account is the same thing as a mailbox and for better or worse, all messages to and from all the user's addresses are presented under the same navtree of folders.

In addition to ordinary user accounts, there are group and department accounts. Groups are discussion forums with all members able to see and reply to all messages. The member list is the responsibility of the group administrator, who is appointed by the system administrator. The member list is not restricted to registered users as outsiders can be invited as guests. Outsiders are expected to participate via HTTP but can request copies of the posts and replies via SMTP for their records. Departments are aimed at providing email services such as technical support, with members sharing the task of replying to an incoming flow of messages. All members can see all incoming messages, but to avoid duplication of effort, only one member can reply to any given message at a time. Ordinary users who are members of groups or departments, see each group/department they belong to, as a folder bearing the group/department name. These appear at the top of the navtree, along with the standard folders such as the inbox.

Folder Automation

Epistula folders, manifest in the webmail navtree, fall into three groups: Standard, omnipresent folders such as the inbox; User defined folders such as 'Family' and 'Friends'; and Automatic folders that depend on correspondent addresses incident in the messages in the mailbox. When the sender or recipient address of a new message (inbound or out), introduces a new domain, a new folder appears in the navtree. This bears the domain name and has the message in question listed under it. Subsequent messages from or to correspondents at the new domain, list under the new folder. By default, once any given address at the domain has two messages in or out, a new folder bearing the address appears as a sub-folder of the domain folder.

The folders do not themselves contain messages. Folders are purely search criteria applied to the mailbox. Messages list under every folder they meet the search criteria of, but do not appear otherwise. As messages are not in folders to begin with, they cannot be moved from one folder to another. However the idea is to eliminate the need to move messages. The Inbox search criteria is "recent and not read, replied to or deleted", where 'recent' means less than 30 'active days' (days when the user logged in, rather than calenda days). All incoming messages that are not identified as junk, qualify for the Inbox and an automatic folder. Over time, either by process or by expiry, messages dissappear from the Inbox but stay in the applicable automatic folder. The junk folder has the exact same search criteria as the inbox, but messages in the junk folder are not placed in automatic folders unless the user takes action to reclassify them. All outgoing messages stay in the applicable automatic folder.

Although messages listed under folders cannot be moved to other folders, automatic folders can be moved under or mirrored to user defined folders. Users can also set the properties of user and automatic folders, to control how they divide. Subfolder formation on new address can be suppressed, placing all messages to and from a given domain in the same folder, thereby capturing the whole dialog between the user and an outside organization. Users may also extend folder search criteria to do such things as separate on subject. Note however that users can only influence the user and automatic folders. They cannot alter the properties of the standard folders.

SPAM, Malware Scanning and Blacklists

SPAM is crudely defined as irrelevant, unsolicited messages sent as adverts, or for malign purposes such as phishing or spreading malware. It is a threat as well as a nuisance, and security, particularly in the case of online services, should always take precedence over convenience. Malware poses by far the greatest threat, because of the propensity to infect user's machines - which in turn are a threat to all online services including mailservers, because the malintent is conducted under the guise of a legitimate and trusted user. User machines usually have their own anti-malware security measures, but this cannot be assumed or dictated by service administrators. It makes sense to build anti-malware measures into the mailserver itself. A common method is to scan the messages against an external database of known threats. The method is effective but not infallible. As the database is updated after the fact, new threats can escape detection. The method also costs money and has a significant performance hit.

Malware however, is only part of the wide SPAM threat/nuisance landscape. As a more general anti-SPAM measure, many mailservers subscribe to one or more external server blacklists, and block messages if the originating server is on any of the lists. The blacklists which identify potentially infected servers and servers known to proliforate junk, have played a big part in improving mailserver security - but mainly by forcing mailserver administrators to close obvious loopholes, in order to get their server off the blacklist! Subscription to a blacklist will reduce SPAM and the likelihood of malware infected messages, but that is all it can do - reduce, not eliminate.

Epistula Security Features

Epistula does not by default, use malware scanning or exteral blacklists. Malware scanning has a significant performance impact and both methods cost money. Small point perhaps but HadronZoo supplies Epistuala as free software and intends it to be free to use. HadronZoo is assessing the feasibility of scanning for specific instructions embedded in scripts and attached documents, that would link to unrelated sites and/or commit data to the local disk. This efficient approach would largely negate the need for a malware database, but it is not currently available and it won't be a game changer if and when it is introduced. For security Epistula relies on the ruthless application of basic measures and adherence to the HadronZoo Security Doctrine (please see www.hadronzoo.com/security). The working assumption is that user machines WILL get infected and that intruders will gain access to usernames and passwords. So the defense objective is to make it extremely difficult (if not impossible), for intruders to use this information - without making authentication arduous for the legitimate users.

That said, for the Epistula webmail (HTTP/S) service, it is expected that users will log in for prolonged periods, all day or even 24/7. This can make more arduous login procedures easier to justify, particularly for those loging in from an unfamiliar IP address. There are many obvious security measures, such as 'two-step' verification via SMS. It is easy for an intruder to infect your PC or phone, but not so easy for the same intruder to infect both. There are non-SMS alternatives. The side entrance can be an alternative URL.

Epistula does not permit multiple simultaneous logins, so intruders armed with username and password will need to consider their timing. The system administrator can set additional constraints on individual accounts, confining users to particular locations and/or timeslots. The response to failed login attempts is not informative, and the system administrator and the user, are notified after the first attempt. After 3 attempts, the IP address is blocked. If an intruder were to somehow gain access to an Epistula webmail account, they are likely to be disappointed with what they can acheive. Users have sending limits set by the administrator, which by default are far from generous. The basic idea is that users write messages by hand. There is no need for them to have sending limits beyond what they can achieve with this method.

For the Epistula SMTP service, a different strategy is applied. SMTP on port 25 is strictly for incoming messages. Nobody can originate messages from this service, not local users, not even the system administrator. If a connecting client gives a local domain address as the sender, SMTP AUTH with be requested if not already supplied, any username and password will suffice and a 250 code is given at the end of the message. The message is then quarentined and the client IP is blocked. SMTP on port 587 will quarentine and block, regardless of the stated sender. Local users are expected to use webmail to originate messages. A submission SMTP service can be configured for the benefit of registered websites, but it must use a higher, non-standard port (above 1023). Needless to say, this port should be behind a firewall.

Epistula Junk Filtration

Epistula maintains a central database of known correspondent domains, which among other things, serves as SPAM blacklist and prefered sender whitelist. This is entirely seperate to any external blacklists that may apply, and to the IP blocking of clients in violation of the protocol. Against each domain is a local user confirmation count, and a point score of how likely the domain is to send junk. The point score in conjunction with tests on the message itself, determines whether the message goes in the recipient Inbox, the Junk Folder, or is rejected (bounced). It should be noted that the point score is partly a count of ignored messages, so the system depends on a certain level of junk reaching the junk folder! It is also the case of course, that the database starts out blank, so it only becomes useful over time. Note also however, that the automated folder regime, lessens the impact of junk bombardment upon users.

The tests applied to messages, are as follows:-

The Content Test:The text content of the text part must match that of the HTML part (if present), and must not match that of earlier messages deemed junk. The text content must not contain phrases deemed to be ofensive, e.g. 'Penis extensions'. The system administrator can apply a list of offensive phrases on behalf of all users, and users are free to add their own.

The Skunk Test: A message is a skunk if it originates from an IP address that cannot be linked by the DNS or other means, to the stated domain of the sender. This test should servers fail the skunk test but not if the hijacked server is the legitimate mailserver for the sender. The skunk test will also fail where backend servers, not registered to the domain are used to originate the message.

The Link Test: The link test fails if the message contains links that are not related to the stated sender domain. The test passes if the message contains no links.

The Human Test:This qurantines messages from unknown senders, sends the sender a link to a verification page, and delete messages where senders fail to verify they are human within a given time period. Messages are blocked in two ways: Firstly where no Reply-To address is supplied, the sender cannot be sent a link to a verification page, so the message simply expires. Secondly where messages are sent out automatically, there is often no provison for human intervention. The drawback with this method is that messages users may want to see, such as a link to a verification page for a website the user is trying to subscribe to, often have no Reply-To address and are sent out automatically! Because of this, the method is not applied to messages from unknown senders which pass the skunk test and have a link which passes the link test.

Summary

Overall, Epistula can take some getting used to. Compared to systems in which folders are predominatly created as a manual process, the automatic folder regime can seem profligate. If the messages are to be retained however, how else should they be organized? It can take time to hunt down a folder among thousands but there is always the direct search method. As a further aid, the message headers in the inbox have a left-pointing arrow which is a direct link to the automatic folder.

Note that an average user metric is used in capacity calculations. It is assumed the average user recieves 200 messages and sends 50, per working day - so a total of around 60,000 messages in and out each year.