|
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.
<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
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.
The
mta/queue
config block controls how messages are stored as they pass through the MTA.
See here for the configuration details.
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.
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.
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.
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.
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.
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.
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.
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
&
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.