Epistula Mail Server: What it is and what it does

HadronZoo::Epistula (or simply Epistula), is a web-configured, combined mailserver and webmail program, aimed at organizations with up to 250 users. The mailserver is standard, but the webmail service is designed around whole conversation threads and borrows ideas from internet forums. Epistula runs under Linux, is written in C++ and is based on the HadronZoo class library, with which it is supplied as part of the HadronZoo download. Epistula, exactly as 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 usually strings but can be email addresses, and user accounts can have multiple email addresses. The direction must be specified for each address, i.e. inbound only, outbound only, or full duplex. There is a 1:1 relationship between user accounts and mailboxes however. All messages to and from all the user's addresses, are held in a single mailbox.

In addition to ordinary user accounts, there are special group and department accounts. Groups operate as discussion forums, with all members able to see and reply to all messages. The list of group members is the responsibility of the group administrator, who is appointed by the system administrator. The list of members is not restricted to registered users, outsiders can be invited as guests. Guests however, do have to log in to the webmail service with thier email address. Departments are similar to groups, but are aimed at providing services such as technical support. The members form the team who share the task of replying to an incoming flow of messages (customer questions). All members can see all incoming messages, but in order to reduce duplication of effort, only one member can reply to any given message at a time.

Accounts and Mailboxes

The general idea of course, is that users log into their accounts, read their messages, reply to them and originate new ones. But if users can be assigned multiple addresses and be party to to any number of groups or departments with addresses that relate to multiple users, what will greet them in their inbox? What folders will appear in the nav-tree and what will be in them? What will users be able to see and do?

User accounts have a single mailbox which contains ALL messages TO all addresses that are dedicated to the user and are enabled to receive, AND all messages FROM all addresses that are dedicated to the user and are enabled for sending. Nowever the mailbox will not contain any messages beyond this set, and assuming the user is not a group or department member, this set will be all the user can access. The navtree will only show the aforementioned standard folders, plus the user's own folders. If however the user is a member of any groups or departments, each applicable group/department will appear at the top of the navtree as a folder bearing the group/department name. These additional group/department folders draw from the respective group/department mailbox, and have sub-folders that map to the group/department folders.

User Folder Automation

Epistula webmail folders are automated and based on confirmed correspondents. A correspondent is confirmed if the user sends a message to the correspondent, or replies to a message from the correspondent. Correspondents can also be confirmed by hitting the 'Confirm' button, which appears in the message view screen when displaying messages to or from an as yet unconfirmed correspondent. Where the address of a newly confirmed correspondent introduces a new domain, a new user folder appears in the navtree. This is initially given a name of the form "domain_name (sender)", e.g. hotmail.com (John Doe). A subsequent newly confirmed correspondent address of the same domain, changes the folder name to just the domain name and places each correspondent address in a separate subfolder. Each additional confirmed correspondent address of the same domain, creates a new subfolder of the domain folder.

Users can improve upon folder automation by creating folders such as 'Family' and 'Friends', and stating which folder particular correspondents belong to. Users can also set folder properties to suppress subfolder formation on new address, putting all messages to and from a domain in the same folder - useful for capturing the whole dialog between the user and an outside organization. Users may also extend the search criteria of folders to separate on subject. Note however that users can only influence the user folders. They cannot alter the properties of the standard folders such as the Inbox.

With Epistula the user mailbox is a message container, but the webmail folders are not. Folders only apply search criteria to the mailbox and list the results. Messages appear in a folder if they qualify by meeting the folder search critiria, and not otherwise. Messages cannot move between folders as they might do in other email systems, since they are not in a folder to begin with. However moving messages is unnecessary as messages will be listed under every folder they qualify for. The Inbox search criteria is fixed as 'recent and not read, replied to or deleted', where 'recent' is defined in terms of 'active days', in which a user is logged in. Assuming a default of 30, the message is recent if it is later than 30 active days ago, rather than 30 calenda days ago. On this basis, all incoming messages initially qualify for the Inbox. If the message is from a confirmed correspondent, it will also qualify for the automatic folder for that correspondent - which in most cases is where user action to manually tidy up the Inbox, would intend to place it. Eventually, either by process or expiry, messages no longer meet the Inbox criteria and so dissappear from Inbox. Thus the Inbox keeps itself tidy which will be a big relief to some.

Security Features and Junk Filtration

Many mailservers rely on an external subscription service to identify blacklisted servers, in order to filter out SPAM. Epistula as supplied, relies on its own security and counter SPAM measures and does not invoke any of these services. However if system administrators want to use a blacklist service, Epistula is open source so the interface would be easy to add.

SPAM is generally taken to mean irrelevant, unsolicited messages sent as adverts, or for malign purposes such as phishing or spreading malware. From this albeit poor definition, it should be clear that the bigger part of this struggle is security, which is the prevail of the mailserver. Relevence is more the prevail of the user. Some users might actually want to extend or modify certain parts of their anatomy. It is not for HadronZoo to comment on taste.

Spammers are particularly keen to hijack mailservers as this covers their tracks. It enables them to originate messages from servers not registered to themselves. The first line of defence is to prevent your own mailserver from being hijacked. To this end, Epistula ensure that all outbound messages are either via webmail which requires user authentication, or via the submission port which requires SMTP Auth. Any attempt to originate an email message from a local user on the SMTP port, results in disconnection and an IP address ban. SMTP Auth failures get the same treatment, as ultimately do webmail authentication failures. The webmail authentication process is more complex as it must accommodate typos and users on the move. Webmail can be unblocked but only by means of codes sent to the user's phone.

The second line of defence is to reject messages from servers that are, or appear to be compromised. This is mainly where the subscription blacklist services would fit in, were any to apply. The second line tests are not conclusive and partly depend on what is known about particular senders. Although junk filtration is the third line of defence, and it is for users to decide what is junk, what users decide has quite an impact as should be apparent in the following tests:-

The Skunk Test: A message is a skunk if it originates from an IP address that cannot be linked by the DNS, to the stated domain of the sender. Most hijacked 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:One effective method of reducing junk is to drive up the cost of sending it. The method is simple: Qurantine messages from unknown senders, send the senders 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: Where no Reply-To address is supplied, sender verification is impossible so the message expires; And where messages are sent out automatically, there is often no provison for human intervention. The problem with this method is that messages users might want to see, such as verification links for websites the user is trying to sign up to, often have no Reply-To address and are sent out automatically! Because of this problem, the method is not applied to messages from unknown senders which pass the skunk test and have a link which passes the link test.

Prefered Sender Locations and other Content Filtration

The forth and final line of defence, is ultimately the user. Some SPAM will get through and some will potentially harm the user's computer. The Epistula server will be OK since it only scans message content, and never processes it in any way. Epistula provides some safeguards when messages are viewed, such as supressing links it does not like. At the end of the day however, there is no substitute for user diligence.

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 Epistula accepts POP3 clients but this a legacy feature which should be considered depricated. The expectation is that user access will be via webmail, and this document is written accordingly. Note also that an average user metric is used in capacity calculations. It is assumed the average user recieves 200 and sends 50 messages per working day, so about 60,000 messages in and out each year.