4 - Configuration

The Mailismus config file is mailismus.xml and it is an XML document which is broken into the following top-level sections, enclosed within the root <mailserver> tag.
The nested <mta> config section represents the SMTP message switch, which lies at the heart of Mailismus.

<mailserver>
    <application>...</application>
    <directory>...</directory>
    <message_store>...</message_store>
    <mta>
        <queue>...</queue>
        <submit>...</submit>
        <deliver>...</deliver>
        <report>...</report>
    </mta>
    <imap>...</imap>
    <pop3server>...</pop3server>
    <pop3download>...</pop3download>
</mailserver>

Follow the links in the left-hand menu for a breakdown of each config section.
Although Mailismus has a vast array of configuration points, they all default to canonical values such that the minimalist config file it ships with ought to let it function as a vanilla mailserver would reasonably be expected to, with very little tinkering.


4.1 - Application Defs

<application>
    <announcehost>mailhost</announcehost>
    <database>...</database>
</application>

announcehost
This is the hostname announced by Mailismus in various SMTP dialogues, and acts as a global default for more specific config items.
In turn, this field defaults to the machine's own hostname, as obtained automatically from the underlying OS.
If you enter the special value %SYSNAME%, it will be replaced by the automatically obtained hostname of the local machine.

database
See separate database section


4.2 - Message Store

The message_store config block defines the Message-Store, which is the means by which Mailismus provides maildrops for local users, ie. it enables Mailismus to function as a destination mailserver.
It is an optional component, and if not enabled, Mailismus acts as a pure SMTP switch, relaying email messages in and out.

See here for the configuration details.


4.3 - The Queue

The mta/queue config block controls how messages are stored as they pass through the MTA.

See here for the configuration details.


4.4 - The Submit Task

The mta/submit config block specifies the Mailismus task which accepts incoming messages into the MTA.
In other words, this is the SMTP-Server component.

This task is a NAFlet class represented by com.grey.mailismus.mta.submit.SubmitTask, as can be seen in the sample naf.xml config file distributed with Mailismus.

See here for the configuration details.


4.5 - The Delivery Task

The mta/deliver config block specifies the Mailismus MTA task which delivers stored messages onwards to their final (or next-hop) destination.
In other words, this is the SMTP-Client component.

This task is a NAFlet class represented by com.grey.mailismus.mta.deliver.DeliverTask, as can be seen in the sample naf.xml config file distributed with Mailismus.

See here for the configuration details.


4.6 - The Reporting Task

The mta/report config block specifies the Mailismus MTA task which processes bounced messages and generates SMTP NDRs.

This task is a NAFlet class represented by com.grey.mailismus.mta.reporting.ReportsTask, as can be seen in the sample naf.xml config file distributed with Mailismus.

See here for the configuration details.


4.7 - IMAP Server

The imap config block specifies the Mailismus IMAP server.

The IMAP server component is a NAFlet class represented by com.grey.mailismus.imap.server.IMAP4Task, as can be seen in the sample naf.xml config file distributed with Mailismus.

See here for the configuration details.


4.8 - POP Server

The pop3server config block specifies the Mailismus POP3 server.

The POP3 server component is a NAFlet class represented by com.grey.mailismus.pop3.server.ServerTask, as can be seen in the sample naf.xml config file distributed with Mailismus.

See here for the configuration details.


4.9 - POP Retriever

The pop3download config block specifies the Mailismus POP3 retriever.
This is not a server-type component at all, but rather a client-side personal utility which can be used even if you're not employing any Mailismus mailserver functionality.

The POP3 retriever is a NAFlet class represented by com.grey.mailismus.pop3.client.DownloadTask, as can be seen in the sample naf.xml config file distributed with Mailismus.

See here for the configuration details.


4.10 - The Directory

The directory config block defines the Directory, which is the mechanism by which Mailismus decides which domains are local, which user accounts (ie. mailboxes) exist on them and how to authenticate access to local user accounts.

See here for the configuration details.


4.11 - Database

As specified in §4.1 above, this config block is nested within the top-level application block, and might look as follows:

<database enabled="Y">
    <drvclass>org.h2.Driver</drvclass>
    <connurl>jdbc:h2:file:/%DIRVAR%/dbdata/smtpq;MVCC=TRUE</connurl>
</database>

This optional config block specifies the database engine to use, for any mailserver component that might require a database.
If absent or marked as not enabled, then no database functionality will be available. This means that if any database-dependent components (eg. SMTP-Server greylisting) are specified, they will fail during Mailismus startup.
NB: The above URL could also be expressed as follows, as it generates the standard path above: jdbc:h2:file:_FILEPATH_;MVCC=TRUE

drvclass
Specifies the database driver (effectively the database type) and if absent it's taken from the greynaf.db.driver system property.
If that's also absent, it defaults to H2 (org.h2.Driver).
The driver classes are listed in the connurl section below.

connurl
The JDBC connection string, to connect/login to the database.

The supported database types are:

You do not have to supply a connurl setting for the embedded databases, as they are automatically created under %DIRVAR%/dbdata, with the default URLs shown above. Note that the URLs specify persistent mode (ie. not in-memory) and the actual examples shown are for the SMTP Queue. Other tables (eg. for Greylisting) are held in their own files, so the smtpq part of the URL would be replaced.

Since the H2 embedded database is the default, that means this minimal config setting is enough to enable it:

<database/>

Note that any ampersands (&) in the connection-URL will need to be expressed as &amp; when embedded in the XML config, to quote the ampersand.

In order to use a particular database engine, you obviously have to have its JDBC driver on your classpath, which by default is not the case for any of them.
You will need to add the driver's JAR to the Mailismus classpath, either via the dependjars config item in the naf.xml config file (see §2 of NAF Guide), or by means of the greynaf.cp system property.

Finally, note that although client/server databases such as Postgresql and MS SQL-Server are supported, they are unsuitable for a production environment, as this would turn database ops into blocking network ops with a vastly higher latency than anything else Mailismus might do, which would defeat the entire design of Mailismus as a non-blocking NAF application.

See §2.3 for additional info on setting up databases.