Dwarf Mail Server 1.1.3
Dwarf Mail Server 1.1.3This document explains setting up of Dwarf Mail Server using the XML-based configuration. See the XML Configuration Guide from the base Dwarf distribution for initial information about the subject. Read it first also if you are new to Dwarf configuration, although you may start directly with the mail server configuration guided by this text, too.
A fully configured mail server may consist of SMTPServer, POPServer and IMAPServer instances. All these services should be added to the MainServer instance, together with other services providing logging, authentication, and so on. Since such server configuration may become too complex, we strongly recommend to separate various independent parts of the server to different XML files. A typical mail server configuration may then look like this:
<?xml version='1.0' encoding='us-ascii'?>
<!DOCTYPE configuration SYSTEM "file:lib/xmlConfiguration.dtd">
<configuration security="on" debug="smtp,pop,imap" trace="" verbose="off">
<!-- MAIN SERVER -->
<service classbase="SK.gnome.dwarf" class=".main.MainServer" name="Main Server">
<set name="logFacility">server</set>
<set name="authFacility">Dwarf</set>
<!-- CONSOLE SERVICE -->
<include url="file:conf/samples/mail/server/console.xml"/>
<!-- LOGGING SERVICE -->
<include url="file:conf/samples/mail/server/logger.xml"/>
<!-- AUTHENTICATION SERVICE -->
<service class=".auth.JAASAuthenticator" name="JAAS Authenticator">
<set name="logFacility">auth</set>
</service>
<!-- SMTP SERVER -->
<include url="file:conf/samples/mail/smtp/smtp.xml"/>
<!-- POP3 SERVER -->
<include url="file:conf/samples/mail/pop/pop.xml"/>
<!-- IMAP4 SERVER -->
<include url="file:conf/samples/mail/imap/imap.xml"/>
</service>
</configuration>
In the rest of this document we will deal with the SMTP, POP3 and IMAP4 server configuration only.
Since each mail server extends the abstract MailServer class, it may also utilize a set of services, which are common to all Dwarf-based mail servers.
First of all, each server must contain at least one MailHost service. Mail host represents an internet domain for which the server will be able to handle mail. The very first and required mail host contained by the server is regarded as default, because it can serve all users for which a required authentication or storage service is not provided by mail host they really belong to.
Mail host may (but the default one must) contain a MailStore service for storing mail messages and folders. It may also contain a UserStore for storing and retrieving user-specific information like runtime data, user configuration options, etc. Finally, some hosts may want to store and read per-user access control lists by utilizing an ACLStore service.
<configuration>
<!-- POP3 SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".pop.POPServer" name="POP3 Server">
<!-- DEFAULT MAIL HOST -->
<service class=".MailHost" name="Default Host">
<set name="hostId">host.domain.com,192.168.0.1</set>
<!-- ... -->
</service>
</service>
</configuration>
The "hostId" attribute specifies the name by which the mail host will be identified by the server. It may be either a fully-qualified host name, a domain name or an IP address, or even a comma-separated mix of these valuse. In that case the mail host will be known by all of these string identifiers.
Mail store provides a place where the mail folders and messages are stored. The service must be added to the particular mail server instance. Currently only a filesystem-based mail store is implemented. However, you may create and use your own mail store implementation, too. The FileMailStore service has three important attributes:
The following example illustrates a basic mail store setup for the POPServer:
<configuration>
<!-- POP3 SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".pop.POPServer" name="POP3 Server">
<!-- DEFAULT MAIL HOST -->
<service class=".MailHost" name="Default Host">
<set name="hostId">host.domain.com,192.168.0.1</set>
<!-- MAIL STORE -->
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
<set name="sharedAccess">true</set>
</service>
</service>
</service>
</configuration>
User store provides a place where the other user-specific information may be stored by the server, like mail aliases database, webmail client configuration data, etc. The service must be added to the particular mail server instance. Currently only a filesystem-based user store is implemented. The FileUserStore service has the same attributes as the previous FileMailStore service, except the sharedAccess attribute, which is not avilable in this case:
<configuration>
<!-- SMTP SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".smpt.SMTPServer" name="SMTP Server">
<!-- DEFAULT MAIL HOST -->
<service class=".smtp.FileSMTPHost" name="Default Host">
<set name="hostId">host.domain.com,192.168.0.1</set>
<set name="aliases">@file:conf/samples/mail/smtp/aliases.properties</set>
<!-- MAIL STORE -->
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
<set name="sharedAccess">true</set>
</service>
<!-- USER STORE -->
<service class=".store.FileUserStore" name="User Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
</service>
</service>
</service>
</configuration>
As you can see, if the default mail and user store implementations are used, they may share the same base directory without causing any conflicts. Note also that in this example of SMTP server configuration we use more specific FileSMTPHost implementation of MailHost which provides some additional features, like mail address aliasing.
ACL store provides a place where the per-user access rights are stored. Currently only the POPServer and IMAPServer can use this facility. The only implementation available is called FileACLStore and stores the ACLs in binary files. It has the same set of attributes as the previous services, too:
<configuration>
<!-- IMAP4 SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".imap.IMAPServer" name="IMAP Server">
<!-- DEFAULT MAIL HOST -->
<service class=".MailHost" name="Default Host">
<set name="hostId">host.domain.com,192.168.0.1</set>
<!-- MAIL STORE -->
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
<set name="sharedAccess">true</set>
</service>
<!-- USER STORE -->
<service class=".store.FileUserStore" name="User Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
</service>
<!-- ACL STORE -->
<service class=".store.FileACLStore" name="ACL Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
</service>
</service>
</service>
</configuration>
SMTP server is the most complex of all Dwarf-based mail servers. It consists of several required services with different purpose. Besides the mail and user store mentioned above there is a mail queue store, a service managing the mail queue and the delivery process, and a couple of services representing the local mail domains. Furthemore, there may be also optional mail agents with filters attached to them for enhanced processing of mail messages.
In the simplest case, you can get the sample configuration file "conf/samples/mail/smtp/smtp.xml", edit the few of required parameters and use such configuration happily. But to really understand the wheel, we will go step by step and explain each service function and its configuration parameters more deeply.
Lets start with the basic SMTP server structure. First of all, there are some attributes common to all TCP/IP servers, which define its dynamic behavior (please refer to the base Dwarf documentation for their meaning):
<!-- SMTP SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".smtp.SMTPServer" name="SMTP Server">
<set name="logFacility">smtp</set>
<set name="queueSize">20</set>
<set name="handlerTimeout">300</set>
<set name="minHandlers">3</set>
<set name="maxHandlers">5</set>
After that, there is a SMTPParameters
service, which is required and provides a set of runtime server parameters.
Many of them may be modified via the management console while the server is
running. The crucial attribute is hostName, which must be a resolvable
domain name of the network host the server is running on. This will also be
the primary local domain of the SMTP server. If omitted, the server will try
to guess the local host name and will use it automatically.
Note also the relayClients attribute, which is commented out in the
example. That means the server will also try to set this attribute automatically
according to the given (or guessed) host name. This parameter tells which clients
will be allowed to relay the SMTP transfer via this server. For the rest of
parameters see the API documentation for SMTPParameters
class.
<!-- SMTP PARAMETERS -->
<service class=".smtp.SMTPParameters" name="SMTPParameters">
<set name="hostName">smtp.foo.bar</set>
<!--set name="relayClients">127.0.0.,.foo.bar</set-->
<set name="authClients"></set>
<set name="noAuthClients"></set>
<set name="authRelayClients"></set>
<set name="noAuthRelayClients"></set>
<set name="rejectFrom"></set>
<set name="rejectTo"></set>
<set name="defaultRelay"></set>
<set name="notifyPostmaster">true</set>
<set name="clientTimeout">300</set>
<set name="serverTimeout">150</set>
<set name="loginDelay">5</set>
<set name="sendServerInfo">false</set>
<set name="maxRecipients">100</set>
<set name="maxMessageSize">2048000</set>
<set name="extensions">AUTH, DSN, SIZE, STARTTLS</set>
<set name="authMethods">LOGIN, PLAIN</set>
<set name="insecureLoginDisabled">false</set>
<set name="etrnNodes">#local, #remote, foo.bar</set>
<set name="deferredNodes">#remote</set>
<set name="autoRunNodes">#process, #local</set>
<set name="deliveryInterval">60</set>
<set name="deliveryTimeout">120</set>
<set name="deferredDeliveryTimeout">720</set>
<set name="deliveryWarningTimeout">4</set>
<set name="caseSensitiveMailbox">false</set>
<set name="identifyUser">false</set>
</service>
SMTP server may also contain some useful commands, accessible via the server console. QueueCmd invokes processing of the queue nodes and prints out the mail queue content, ReloadCmd may be used to reload mail alias databases and CheckCmd command checks the integrity of mail stores.
<!-- MAIL COMMANDS -->
<service class=".smtp.cmd.QueueCmd" name="queue"/>
<service class=".smtp.cmd.ReloadCmd" name="reload"/>
<service class=".store.cmd.CheckCmd" name="check"/>
The next service is really important - it is a QueueManager.
It manages the processing of mail queues and handles also the local and remote
deliveries of queued messages. Furthemore, it handles also the processing of
mail message by mali agents (which we will explain later). Since it is in fact
a mutli-threaded server, it provides some common attributes for modifying the
dynamic server behavior, too. The interval attribute specifies in minutes
how often the mail queue will be scanned for messages waiting to be processed
and delivered.
After that, there is a FileMailQueue
service, which is a filesystem-based implementation of MailQueue
interface. This service handles storing of messages in the mail queue. The queueDir
attribute specifies the directory where the mail queue will be kept. The checkpoint
attribute defines an interval in minutes of scanning the queue for finished
messages. If deleteFinished is true, those messages will be permanently
removed from the queue in the specified intervals.
Next is the DNSService, which is required only for the remote mail
delivery. Its server attribute must refer to a reachable functional
DNS name server, which will be used for the MX record lookups. You may omit
this service if your server will use a dedicated SMTP relay for all remote deliveries,
or it will not perform remote deliveries at all.
<!-- QUEUE MANAGER -->
<service class=".smtp.QueueManager" name="Queue Manager">
<set name="handlerTimeout">300</set>
<set name="minHandlers">3</set>
<set name="maxHandlers">5</set>
<set name="interval">10</set>
<!-- MAIL QUEUE -->
<service class=".smtp.FileMailQueue" name="Mail Queue">
<set name="queueDir">mail/queue</set>
<set name="deleteFinished">true</set>
<set name="checkpoint">30</set>
</service>
<!-- DNS SERVICE -->
<service class="SK.gnome.dwarf.utils.dns.DNSService" name="DNS Service">
<set name="server">dns.foo.bar</set>
<set name="timeout">30</set>
<set name="stream">false</set>
</service>
</service>
See also the SMTP Server Architecture document for more details on the queue managing process and some related configuration options.
The last is the necessary TCP/IP listener service, which will listen on the specified port and forward the client connections to the server for further processing.
<!-- TCP LISTENER -->
<service class="SK.gnome.dwarf.tcpip.TCPListener" name="SMTP Listener">
<set name="port">25</set>
</service>
</service>
There is one more type of service, which is necessary for the server operation and we have not mentioned it yet - the SMTPHost. It represents a local mail domain for which the server will be able to receive and process mail messages.
SMTP host in the context of Dwarf Mail Server is a representation of the particular local mail domain. Each server must have at least one SMTPHost configured, which will represent a primary mail domain, according to the "hostName" parameter of the previously mentioned SMTPParameters:
<service classbase="SK.gnome.dwarf.mail" class=".smtp.SMTPServer" name="SMTP Server">
<!-- ... -->
<!-- DEFAULT MAIL HOST -->
<service class=".smtp.FileSMTPHost" name="Default Host">
<set name="hostId">host.domain.com</set>
<set name="aliases">@file:conf/samples/mail/smtp/aliases.properties</set>
<!-- MAIL STORE -->
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
<set name="sharedAccess">true</set>
</service>
<!-- USER STORE -->
<service class=".store.FileUserStore" name="User Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
</service>
</service>
<!-- VIRTUAL MAIL HOST -->
<service class=".smtp.FileSMTPHost" name="Virtual Host (FOO.BAR)">
<set name="hostId">foo.bar</set>
<set name="aliases">@file:conf/samples/mail/smtp/foo_bar.properties</set>
</service>
<!-- ... -->
</service>
This specifies that all messages to "@host.domain.com" are local for this server and it should try to deliver them to a local mailbox.
You can see also another SMTPHost representing the "foo.bar" domain, so the messages sent to "@foo.bar" will also be received by the server and delivered locally. We call such hosts a virtual mail hosts and will cover them later.
Each SMTPHost provides a basic mail aliasing mechanism. The FileSMTPHost is an implementation based on the filesystem. It provides a database of mail aliases through a plain text file with the familiar java.util.Properties syntax. The "aliases" attribute specifies the location of the alias file (as in the above example), although the aliases may be also specified directly in the XML element:
<!-- ALIASES IN XML FILE -->
<service class=".smtp.FileSMTPHost" name="Default Host">
<set name="hostId">host.domain.com</set>
<set name="aliases">
info=joe
webmaster=jim,jill@foo.bar
</set>
<!-- ... -->
</service>
Note that in the above example the alias "info" is mapped to the local address "joe". In fact, it is mapped to "joe@host.domain.com", since the address does not contain a domain part. In the next line the "webmaster" alias is then mapped to "jim@host.domain.com" as well as "jill@foo.bar" address.
The UserStore provides another level of aliasing, if it is included in the SMTPHost. It contains a special method for alias expanding. The FileUserStore implements this method by searching for a file named ".forward" in the user subdirectory. If found, the alias database is read from it and the given alias is expanded to a list of addresses in the same way as stated above.
The file-based alias databases may be reloaded in any time via the ReloadCmd console command. The XML-based ones are static and may be refreshed only by restarting the whole server process. The ".forward" files are read and checked each time the alias expansion process is invoked.
Mail agents are derived from the MailAgent class. They are special services, which get queued messages on the input and process them, applying the particular application logic. They may alter the message delivery process and/or create and send new messages based on the processed ones. Mail agents may be grouped together to provide a more sophisticated processing chain. A typical example of mail agent may be an antispam or antivirus service.
Mail filters extend the MailFilter class and decide which messages will be processed by the containing agents. Each agent may contain more than one mail filter. In this case, the filters will create a pipelined filter chain.
Mail agents are added to the SMTPServer instance via the special MailAgentServer container:
<service classbase="SK.gnome.dwarf.mail" class=".smtp.SMTPServer" name="SMTP Server">
<!-- ... -->
<!-- MAIL AGENTS -->
<service class=".smtp.proc.MailAgentServer" name="Mail Agent Server">
<!-- ANTI-SPAM AGENT -->
<service class=".smtp.proc.agent.AntiSpam" name="Anti Spam">
<set name="required">true</set>
<set name="failedState">failed</set>
<set name="bannedClients">banned.client.com</set>
<set name="bannedDomains">@spammer.com</set>
<set name="checkHeaders">true</set>
<set name="checkAddresses">false</set>
<set name="checkBody">false</set>
<set name="maxMessageHops">20</set>
<service class=".smtp.proc.filter.AllRecipients" name="All"/>
</service>
<!-- AUTO-REPLY AGENT -->
<service class=".smtp.proc.agent.AutoReply" name="Auto Reply">
<set name="required">false</set>
<set name="encoding">us-ascii</set>
<set name="delay">720</set>
<service class=".smtp.proc.filter.HostIsLocal" name="Host Is Local"/>
</service>
</service>
<!-- ... -->
</service>
The "required" attribute of MailAgent class tells whether the processing chain will be interrupted if an error occurs during the message processing. In other words, if this paramater is set to true, the message processing will be immediatelly interrupted in the case of an error, the current set of recipients passed through the attached mail filters will be marked as finished+failed and the message will be returned to the mail queue. If the value is true, the error will be logged only and the message processing will continue by passing the message to other agents.
For the complete list of available mail filters and agents see the SK.gnome.dwarf.mail.smtp.proc.filter and SK.gnome.dwarf.mail.smtp.proc.agent packages.
POP3 server is relatively simple. It has the inherited attributes of generic TCP/IP server and requires a POPParameters as well as a default MailHost service with its mail store:
<!-- POP3 SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".pop.POPServer" name="POP3 Server">
<set name="logFacility">pop</set>
<set name="handlerTimeout">300</set>
<set name="minHandlers">1</set>
<set name="maxHandlers">3</set>
<!-- POP Parameters -->
<service class=".pop.POPParameters" name="POP3 Parameters">
<set name="sendServerInfo">false</set>
<set name="clientTimeout">600</set>
<set name="loginDelay">5</set>
<set name="extensions">SASL, STLS, TOP, UIDL, USER</set>
<set name="authMethods">LOGIN, PLAIN</set>
<set name="insecureLoginDisabled">false</set>
<set name="checkACL">false</set>
<set name="updateACL">false</set>
</service>
<!-- DEFAULT MAIL HOST -->
<service class=".smtp.FileSMTPHost" name="Default Host">
<set name="hostId">host.domain.com,192.168.0.1</set>
<!-- MAIL STORE -->
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
<set name="sharedAccess">true</set>
</service>
</service>
<!-- TCP LISTENER -->
<service class="SK.gnome.dwarf.tcpip.TCPListener" name="POP3 Listener">
<set name="port">110</set>
</service>
</service>
IMAP4 server configuration is very similar to POP3 server. It consists of analogical services. In addition, it requires UserStore for storing per-user folder subscriptions and it may contain also an ACLStore to manage the access control lists:
<!-- IMAP SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".imap.IMAPServer" name="IMAP4 Server">
<set name="logFacility">imap</set>
<set name="handlerTimeout">300</set>
<set name="minHandlers">3</set>
<set name="maxHandlers">5</set>
<!-- IMAP PARAMETERS -->
<service class=".imap.IMAPParameters" name="IMAP Parameters">
<set name="clientTimeout">1800</set>
<set name="loginDelay">5</set>
<set name="sendServerInfo">false</set>
<set name="extensions">ACL, AUTH, LITERAL+, NAMESPACE, STARTTLS</set>
<set name="authMethods">LOGIN, PLAIN</set>
<set name="insecureLoginDisabled">false</set>
<set name="checkACL">false</set>
<set name="updateACL">false</set>
</service>
<!-- DEFAULT MAIL HOST -->
<service class=".smtp.FileSMTPHost" name="Default Host">
<set name="hostId">host.domain.com,192.168.0.1</set>
<!-- MAIL STORE -->
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
<set name="sharedAccess">true</set>
</service>
<!-- USER STORE -->
<service class=".store.FileUserStore" name="User Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
</service>
<!-- ACL STORE -->
<service class=".store.FileACLStore" name="ACL Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/user</set>
</service>
</service>
<!-- TCP LISTENER -->
<service class="SK.gnome.dwarf.tcpip.TCPListener" name="IMAP4 Listener">
<set name="port">143</set>
</service>
</service>
Configuring a usefull mail server requires one more step - preparing and setting up the user accounts. Since Dwarf Mail Server uses the core Dwarf framework's authentication mechanism, this task is completely separated from the mail server. The authentication (i.e. user login and logout) is configured globally per application and may be shared by all running Dwarf-based services, not only the mail server. Please refer to the framework documentation, namely the Dwarf Security Guide for more information.
In the simplest case, you can use one of the available login modules provided
by the framework and setup the required configuration file and user database
(plain text file, SQL database, Unix shadow password suite, etc.). The POP3
and IMAP4 server will then authenticate against the given database. The SMTP
server does not use authentication for delivering to mailboxes unless you set
the "identifyUser" SMTP parameter to true. Instead, it simply
checks whether a mail store exists for the given user. However, if you setup
your client to initiate the authentication using the ESMTP protocol extension,
the server will have to authenticate the subject using the underlying authentication
mechanism, too.
(Please note that you may force server to create the user mailbox automatically
by simply accessing it via POP3 or IMAP4 protocol for the first time, if the
FileMailStore
service is configured for automatic creation of mail stores.)
Authorization (i.e. checking of user rights) is based on subject-based permissions using the MailPermission class. Only POP3 and IMAP4 servers perform the user authorization, SMTP server does not. POP3 server requires MailPermission "rd" to be granted to the authenticated subject in order to read and delete the messages from its mailbox. IMAP4 server requires full MailPermission "lrswicda1" for complete functionality, although only subset of the permissions may be granted to the subject to limit its rights, too.
Mail permissions may be granted to a subject in two ways - either via a subject-base
security policy or via the ACLStore
service. The first one is covered also by the previously mentioned Dwarf
Security Guide document.
In the sample applications bundled with the distribution the mail permission
is granted only to users, which are members of the special "mail"
security role. Please note also that the subject-based permissions in Dwarf
are always granted to the particular service, referred by its full name. The
subjects in mail server are authenticated in the context of particular MailHost
service, which also supports the custom authentication for virtual mail hosts.
In the following example only subject authenticated by the particular service
and belonging to the given role will be granted the specified MailPermission:
// grant permission to access mail via various protocols
grant principal SK.gnome.dwarf.auth.ServicePrincipal "Main Server/POP3 Server/Default Host",
principal SK.gnome.dwarf.auth.RolePrincipal "mail"
{ permission SK.gnome.dwarf.mail.auth.MailPermission "*", "rd";
};
grant principal SK.gnome.dwarf.auth.ServicePrincipal "Main Server/POP3 Server/Virtual Host",
principal SK.gnome.dwarf.auth.RolePrincipal "mail"
{ permission SK.gnome.dwarf.mail.auth.MailPermission "*", "rd";
};
grant principal SK.gnome.dwarf.auth.ServicePrincipal "Main Server/IMAP4 Server/Default Host",
principal SK.gnome.dwarf.auth.RolePrincipal "mail"
{ permission SK.gnome.dwarf.mail.auth.MailPermission "*", "lrswipcda1";
};
grant principal SK.gnome.dwarf.auth.ServicePrincipal "Main Server/IMAP4 Server/Virtual Host",
principal SK.gnome.dwarf.auth.RolePrincipal "mail"
{ permission SK.gnome.dwarf.mail.auth.MailPermission "*", "lrswipcda1";
};
The second way is to add an ACLStore implementation to the particular MailHost instance. In this case the server will not check the subject-based permissions, instead it will use permissions obtained from the given ACL store. However, this will probably require to create a special client UI (at least a console command) for managing the server-side access control lists. Note also that IMAP4 and POP3 server has a special parameter for enabling the automatic updates of ACLs when the mail store is modified, too.
Virtual mail hosts are represented by MailHost services (or more specific SMTPHost in the case of SMTP server). They provide authentication facility as well as storage services for each particular internet domain the server handles mail for. The very first mail host in the server is called default, all others are regarded as virtual.
The virtual hosting mechanism works as follows: if user's login name or recipient's address is simple, like "joe", it will always be handled by the default mail host. But if it contains also a domain part, like "joe@public.com", a particular MailHost instance for that domain is checked first if it provides local authentication and storage facility for the given user. If not, a facility from the default mail host is used automatically. In both cases, the login name or local part of the e-mail address is first translated to the virtual host-specific local form via the mapVirtualUser(String) method. By default, the translation process simply strips the given name of its domain part. This may be disabled by setting the "stripDomain" attribute of the particular MailHost to false.
The following are basic principles of configuring virtual hosts:
In the following example, there are three mail hosts defined. The first one is default - it contains its own mail store but uses the default authentication facility. The second one uses also its own mail store and shares the same global authentication facility as the first one. The third one uses the mail store of the first (default) one but uses its own authentication facility specified by the "authFacility" attribute:
<!-- DEFAULT MAIL HOST -->
<service class=".MailHost" name="Default Host">
<set name="hostId">host.domain.com</set>
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/default</set>
</service>
</service>
<!-- VIRTUAL MAIL HOST (FOO.BAR) -->
<service class=".MailHost" name="Virtual Host (FOO.BAR)">
<set name="hostId">foo.bar</set>
<set name="stripDomain">true</set>
<service class=".store.FileMailStore" name="Mail Store">
<set name="autoCreate">true</set>
<set name="userBaseDir">data/foo_bar</set>
</service>
</service>
<!-- VIRTUAL MAIL HOST (SPAM.EGG) -->
<service class=".MailHost" name="Virtual Host (SPAM.EGG)">
<set name="authFacility">Spam_Egg</set>
<set name="hostId">spam.egg</set>
<set name="stripDomain">true</set>
</service>
Configuring a mail server for encrypted connections consists of three steps. The first one is to enable the corresponding protocol extension ("STLS" for POP3 and "STARTTLS" for SMTP/IMAP4) via the server parameters. The second one is to configure a key store containing the server certificate:
<!-- IMAP SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".imap.IMAPServer" name="IMAP4 Server">
<set name="logFacility">imap</set>
<set name="handlerTimeout">300</set>
<set name="minHandlers">3</set>
<set name="maxHandlers">5</set>
<set name="keyStoreURL">file:conf/testkey.crt</set>
<set name="keyStorePwd">123456</set>
<set name="keyPwd">abcdef</set>
<set name="SSLProtocol">TLSv1</set>
<!-- ... -->
</service>
The last step is to add the SSLListener class to the particular server instance:
<!-- IMAP SERVER -->
<service classbase="SK.gnome.dwarf.mail" class=".imap.IMAPServer" name="IMAP4 Server">
<!-- ... -->
<!-- TCP LISTENER -->
<service class="SK.gnome.dwarf.tcpip.TCPListener" name="IMAP4 Listener">
<set name="port">143</set>
</service>
<!-- SSL LISTENER -->
<service class="SK.gnome.dwarf.tcpip.SSLListener" name="IMAP4 SSL Listener">
<set name="port">995</set>
</service>
</service>
For testing purposes you may use the "bin/keystore.bat" or "bin/keystore.sh" script to create a sample server certificate.
Return to the main page.