(debian-policy.info)Mail transport delivery and user agents

---

Next: News system configuration Prev: Web servers and applications Up: Customized programs

---

Enter node , (file) or (file)node

11.6 Mail transport, delivery and user agents
=============================================

Debian packages which process electronic mail, whether mail user agents
(MUAs) or mail transport agents (MTAs), must ensure that they are
compatible with the configuration decisions below.  Failure to do this
may result in lost mail, broken ‘From:’ lines, and other serious brain
damage!

The mail spool is ‘/var/mail’ and the interface to send a mail message
is ‘/usr/sbin/sendmail’ (as per the FHS). On older systems, the mail
spool may be physically located in ‘/var/spool/mail’, but all access to
the mail spool should be via the ‘/var/mail’ symlink.  The mail spool is
part of the base system and not part of the MTA package.

All Debian MUAs, MTAs, MDAs and other mailbox accessing programs (such
as IMAP daemons) must lock the mailbox in an NFS-safe way.  This means
that ‘fcntl()’ locking must be combined with dot locking.  To avoid
deadlocks, a program should use ‘fcntl()’ first and dot locking after
this, or alternatively implement the two locking methods in a non
blocking way.  (1) Using the functions ‘maillock’ and ‘mailunlock’
provided by the ‘liblockfile*’ packages is the recommended way to
accomplish this.

Mailboxes are generally either mode 600 and owned by user or mode 660
and owned by ‘user:mail’.  (2) The local system administrator may choose
a different permission scheme; packages should not make assumptions
about the permission and ownership of mailboxes unless required (such as
when creating a new mailbox).  A MUA may remove a mailbox (unless it has
nonstandard permissions) in which case the MTA or another MUA must
recreate it if needed.

The mail spool is 2775 ‘root:mail’, and MUAs should be setgid mail to do
the locking mentioned above (and must obviously avoid accessing other
users’ mailboxes using this privilege).

‘/etc/aliases’ is the source file for the system mail aliases (e.g.,
postmaster, usenet, etc.), it is the one which the sysadmin and
‘postinst’ scripts may edit.  After ‘/etc/aliases’ is edited the program
or human editing it must call ‘newaliases’.  All MTA packages must come
with a ‘newaliases’ program, even if it does nothing, but older MTA
packages did not do this so programs should not fail if ‘newaliases’
cannot be found.  Note that because of this, all MTA packages must have
‘Provides’, ‘Conflicts’ and ‘Replaces: mail-transport-agent’ control
fields.

The convention of writing ‘forward to address’ in the mailbox itself is
not supported.  Use a ‘.forward’ file instead.

The ‘rmail’ program used by UUCP for incoming mail should be
‘/usr/sbin/rmail’.  Likewise, ‘rsmtp’, for receiving
batch-SMTP-over-UUCP, should be ‘/usr/sbin/rsmtp’ if it is supported.

If your package needs to know what hostname to use on (for example)
outgoing news and mail messages which are generated locally, you should
use the file ‘/etc/mailname’.  It will contain the portion after the
username and ‘@’ (at) sign for email addresses of users on the machine
(followed by a newline).

Such a package should check for the existence of this file when it is
being configured.  If it exists, it should be used without comment,
although an MTA’s configuration script may wish to prompt the user even
if it finds that this file exists.  If the file does not exist, the
package should prompt the user for the value (preferably using
‘debconf’) and store it in ‘/etc/mailname’ as well as using it in the
package’s configuration.  The prompt should make it clear that the name
will not just be used by that package.  For example, in this situation
the ‘inn’ package could say something like:

     Please enter the "mail name" of your system.  This is the hostname portion
     of the address to be shown on outgoing news and mail messages.  The
     default is syshostname, your system's host name.

     Mail name ["syshostname"]:

where syshostname is the output of ‘hostname --fqdn’.

   ---------- Footnotes ----------

   (1) If it is not possible to establish both locks, the system
shouldn’t wait for the second lock to be established, but remove the
first lock, wait a (random) time, and start over locking again.

   (2) There are two traditional permission schemes for mail spools:
mode 600 with all mail delivery done by processes running as the
destination user, or mode 660 and owned by group mail with mail delivery
done by a process running as a system user in group mail.  Historically,
Debian required mode 660 mail spools to enable the latter model, but
that model has become increasingly uncommon and the principle of least
privilege indicates that mail systems that use the first model should
use permissions of 600.  If delivery to programs is permitted, it’s
easier to keep the mail system secure if the delivery agent runs as the
destination user.  Debian Policy therefore permits either scheme.