MeTA1 and other modern MTAs

Last Update 2010-12-01
[Main] [Release] [Documentation] [Misc]

Note: this is work in progress and far from complete.

Basic Goals

The basic goals for all modern MTAs are the same: We don't need to talk about these two requirements here; they are absolutely essential and properly handled by modern MTAs (by design and by implementation).

Some additional goals are:

Architecture

MeTA1 is a modern message transfer agent (MTA) comparable to qmail and postfix. All of these MTAs have a common architecture: they use several (communicating) modules in contrast to monolithic MTAs like sendmail or exim. The architecture of a modern MTA consists of:

Implementation

One of the main differences between MeTA1, qmail, and postfix is the implementation of the MTA modules.

In MeTA1 all modules are implemented as persistent processes: they are started once and keep on running until shutdown. MeTA1 uses POSIX threads for the address resolver and queue manager, and statethreads for the SMTP server and client.

At the other end of the spectrum is the approach taken by qmail: almost all processes are started only on demand and operate on a single message after which they terminate.

A middle approach is taken by postfix: most processes terminate after a certain time or after they processed a certain number of messages.

Each of these approaches has advantages and disadvantages, some of which depend on the operating system (OS) on which the MTA is running. For example, some OS perform fairly bad with respect to starting processes, which makes qmail perform worse than the other MTAs on them. MeTA1 actually allows to combine multiple processes with multiple threads, which in turn makes it possible to fine-tune it for the specific performance profiles of different OSs.

Efficiency

The efficiency of most modern MTAs is usually limited by the amount of disk I/O operations that the underlying hardware can provide. As the operation of an MTA requires that each message must be safely written to disk before it is accepted, this is the common limiting factor in MTA performance. Minor differences depend on the amount of disk I/O performed for each messages.

Configuration

This is one of the main differences between modern MTAs. Whether a user actually likes the configuration of some software strongly depends on personal tastes. There are only few objective criteria that multiple users can agree upon. Simple things like syntactical elements can cause strong arguments between various styles even though they may only differ in the syntactic sugar they use.

qmail is basically configured via lots of (small) files.

MeTA1 uses a single configuration file with free layout which mostly follows C syntax.

postfix uses two different configuration files: master.cf has a fixed layout where each logical line defines a single service (its syntax is probably inspired by inetd.conf(5)). main.cf uses a simple line oriented layout which is of the form
parameter = value

Extendibility

MeTA1 supports a pmilter interface similar to the milter interface of sendmail 8 for filtering in the SMTP server. It is also planned to provide a plugin architecture for the other modules.

qmail can be extended by writing C code. As there has not been a new release for many years, the API is stable.

postfix supports most of the milter interface of sendmail 8 as well as some of its own extensions for content filtering.

Documentation

An important feature of software (but often neglected) is its documentation. Some MTA spread their documentation over multiple files (maybe in different directories) which may even use different formats or styles.

Feature Set

For a list of features of the various MTAs, please see their respective documentation.

Misc

MTA nowadays should check whether a local recipient address is actually valid. It is a bad idea to accept mail for all addresses in a local domain first, and then check later whether the recipient actually exists (even though some people claim that this is useful to defeat dictionary attacks): what should be done with the undeliverable mail? Creating a DSN is in general a bad idea because most sender addresses are fake. Dumping the mail without notification is a bad idea for those cases where a legitimate sender made a typo and now the mail is gone without any kind of notification.
Taking this one step further is to validate also sender addresses if a local domain is used. This is something MeTA1 does and it rejects a surprisingly high number of spam mails. Doing this is rather complicated in some other MTAs, e.g., sendmail.

How to choose an MTA?

It depends...

Most people do not (actively) choose an MTA, but they simply use what comes with their OS (which may explain why sendmail was so popular). Those who actively choose an MTA do it usually based on personal preferences instead of objective criteria. This may be as strange as
I don't like the author/community of xyz
or as simple as
I prefer this configuration file syntax/style.

Other factors (besides those listed above) may include (free/commercial) support and (active) development.


[Main] [Release] [Documentation] [Misc]

Copyright 2010 © Claus Aßmann; all rights reserved.