authproxyd [-v] [-f config_file]

authproxyd is a daemon process that provides authentication services to the M-Store imapd and pop3d servers. Specifically, it processes LOGIN and AUTHENTICATE PLAIN IMAP4 commands, as well as the USER and PASS POP3 commands.

This server fulfills two roles: isolation of all code requiring superuser privileges into a single process, and to provide proxy authentication services to clients that do not understand SASL based authentication.

authproxyd must be run as the superuser and will change to the runtime-user as defined in the configuration file except when running against a protected authentication database (for example, the shadow mechanism). authproxyd is normally invoked from the storemgr daemon process as part of the set of managed server processes that make up a running message store. All stop and restart operations for authproxyd should be performed using the rc.m-store boot script.

authproxyd will not run if any database files are missing, in such a case a backup containing all database files must be restored.

If authproxyd was invoked by storemgr, then the server cannot be independently shut down, as storemgr will automatically restart it. To shut down the server, you must use the rc.m-store boot script.

AUTHENTICATE login password\r\n

OK [text message] or NO[text message]

The following options are set in the M-Store configuration file. If an option is not present in the file, its default is assumed.

---

Note: Default values appear in square brackets at the head of the description text. Some options have no default value; these are listed with <no default>.

---

Depending on the facilities provided by your underlying operating system, authproxyd supports one or more authentication mechanisms. The mechanism is selected by the authproxy-authmech configuration variable where the associated value is one of the following:

authproxyd can be configured to automatically migrate users from an insecure authentication mechanism (that is, plaintext) to a more secure one (that is, CRAM-MD5). The authproxy-legacy-authmech configuration option specifies a fallback authentication mechanism to be used if the account being authenticated does not exist in the authmech authentication environment. If this fallback authentication succeeds, authproxyd creates an account in the authmech authentication environment using the account name and password provided in the authentication request. For example, a site wanting to migrate account information from a local password file to an authdb account database would invoke authproxyd with a configuration file containing the following:

authproxy-authmech authdb
authproxy-legacy-authmech getpwent

The first time a given account attempts to authenticate using CRAM-MD5 or DIGEST-MD5 the AUTHENTICATE command fails (since the account does not exist in the internal account database), and the client falls back to using an AUTHENTICATE PLAIN or LOGIN command. If this fallback authentication succeeds, authproxyd creates an account in the internal account database, using the account name and password provided in the authentication request. The next time that account attempts to log in to the server it will be able to do so using the native SASL CRAM-MD5 or DIGEST mechanism.

legacy_authmech can specify any supported authentication mechanism, however, the only valid authmech when doing account migration is authdb.

The kerberos4 authentication driver consumes considerable resources. To perform an authentication it must obtain a ticket-granting-ticket from the TGT server on every authentication request. The Kerberos library routines that obtain the TGT also create a local ticket file, on the reasonable assumption that a local ticket file is needed for use by other Kerberos applications. These ticket files are unusable by authproxyd, however, there is no way to prevent their creation. The overhead of accessing these ticket files causes serious performance degradation on busy mail servers. We recommend against using this driver. (Kerberos was never intended to be used in this manner; the best option is to deploy Kerberos-aware clients.)

imapd [-f config_file]

M-Store is an IMAP4 revision 1 (RFC2060) compliant protocol server interface to the message store. imapd must be run as the superuser and will change to the runtime-user as defined in the configuration file for normal operation. imapd is normally invoked from the storemgr daemon process as part of the set of managed server processes that make up a running message store. All stop and restart operations for imapd should be performed using the rc.m-store boot script.imapd can use SASL to authenticate users. The SASL authentication mechanisms PLAIN and CRAM-MD5 are built in, and other available mechanisms may also be used by placing the appropriate plugin into the M-Store plugin directory executable-base-path/lib/plugins/, where executable-base-path is defined in the M-Store\ configuration file.

Normally, the daemon process is invoked from the rc.m-store boot script.

M-Store\'s imapd supports the following option:

imapd supports the following standards track IMAP4 extensions: ACL ( RFC 2086), LITERAL+ (RFC 2088), NAMESPACE (RFC 2342), QUOTA (RFC 2087), and UIDPLUS (RFC 2359).

lmtpd [-f config_file]

lmtpd is a daemon process that provides a LMTP (RFC2033) message injection interface to the MessagingDirect message store. It provides numerous benefits over deliver, and is the preferred delivery interface between the MTA and the message store.

lmtpd must be run as the superuser and will change to the runtime-user as defined in the configuration file for normal operation. lmtpd is normally invoked from the storemgr daemon process as part of the set of managed server processes that make up a running message store. All stop and restart operations for lmtpd should be performed using the rc.m-store boot script.

By default, lmtpd rejects all messages containing non-ASCII characters in the message headers. To maintain backward compatibility with MUA software that does not properly MIME-encode non-ASCII header data, add the line:  allow8bitheaders to the ms.conf file. This line forces lmtpd to accept the message by stripping the high-bit from any non-ASCII characters.

By default, lmtpd delivers to a user's INBOX. To deliver to a specific mailbox, append the mailbox name to the recipient's local name. For example:

rcpt to: joe+important/March2000@foobar.com 

will deliver the message to the mailbox:

user/joe/important/March2000

where joe@foobar.com is a valid user in the message store. To deliver to a shared mailbox, append the mailbox name to the lmtp-shared-name name defined in ms.conf.

rcpt to: shared+bugreports@foobar.com

This method of delivery is known as Plus-Addressing. Plus-Addressing is not a standard, but it does result in a valid RCF822 address.

lmtpd does not (yet) support the LMTP AUTH command. The access permissions on the directory containing the named socket determine who has access to the LMTP server. Any process capable of connecting to the named socket can inject messages into any INBOX in the message store. Only the server runtime user should have access to the named socket directory.

lmtpd will not run if any database files are missing, in such a case a backup containing all database files must be restored. If lmtpd was invoked by storemgr, then the server cannot be independently shut down, as storemgr will automatically restart it. To shut down the server, you must use the rc.m-store boot script.

pop3d [-f config_file]

pop3d is a POP3 (RFC1939) protocol server interface to the message store. It is a daemon process and is normally invoked from the rc.mdstore boot script. pop3d must be run as the superuser and will change to the runtime-user as defined in the configuration file for normal operation. pop3d is normally invoked from the storemgr daemon process as part of the set of managed server processes that make up a running message store. All stop and restart operations for pop3d should be performed using the rc.m-store boot script.

The POP3 server is only capable of serving the authenticated user's IMAP4 INBOX folder. This is not a bug, it is a restriction of the POP3 protocol. If access to multiple folders are required, use the IMAP4 protocol.

pop3d enforces exclusive access to the user's INBOX folder: a user can have only one POP3 session active at any time. Access to the folder via another POP3 session is denied while the original POP3 session has the maildrop open.

If the file ms-path/etc/nologin exists, pop3d will shut down the connection. The first line of the file will be sent to the client as an [ALERT] message before the connection is closed. The ms-path parameter is defined in M-Store's configuration file ms.conf.

pop3d can use SASL (via APOP) to authenticate users. The mechanisms PLAIN and CRAM-MD5 are built in, and other mechanisms can be used by placing the appropriate plugin into M-Store's plugin directory:

executable-base-path/lib/plugins/

where executable-base-path is defined in M-Store's configuration file.

pop3d will not run if any database files are missing. In such a case, a backup containing all database files must be restored.

If pop3d was invoked by storemgr , then the server cannot be independently shut down, as storemgr will automatically restart it. To shut down the server, you must use the rc.m-store boot script.