MH-TAILOR(5mh) | MH-TAILOR(5mh) |
mh-tailor, mts.conf - mail transport configuration for nmh message handler
The file /etc/nmh/mts.conf defines run-time options for those nmh programs which interact (in some form) with the message transport system. At present, these (user) programs are: ap, inc, msgchk, post, rcvdist, and rcvpack.
Each option should be given on a single line. Blank lines and lines which begin with `#' are ignored. The options available along with default values and a description of their meanings are listed below:
mts:
If you use smtp, this will enable a direct SMTP interface in nmh. When sending mail, instead of passing the message to the mail transport agent, post will open a socket connection to the mail port on the machine specified in the servers entry.
If you use sendmail/smtp, then post will send messages by forking a local copy of sendmail. It will still speak SMTP with this local copy of sendmail. For backward compatibility, sendmail/smtp can be abbreviated to sendmail.
The third alternative, sendmail/pipe, also forks a local copy of sendmail but feeds the message directly to it, using sendmail -t. This replaces the old, undocumented spost mechanism and retains some of its limitations, such as lack of support for the “Dcc:” header field, as described in the send and post manual pages.
localname:
If you are using POP to retrieve new messages, you may want to set this value to the name of the POP server, so that outgoing messages appear to have originated on the POP server.
localdomain:
This should only be needed, if for some reason nmh is not able to fully qualify the hostname returned by the system (e.g. uname, gethostname, etc.).
clientname:
Although the HELO command is required by RFC 821, many SMTP servers do not require it. Early versions of SendMail will fail if the hostname given in the HELO command is the local host. Later versions of SendMail will complain if you omit the HELO command. If you run SendMail, find out what your system expects and set this field if needed.
systemname:
mmdfldir: /var/mail
mmdflfil:
spoollocking: fcntl
fcntl dot flock lockf
maildelivery: /usr/lib/mh/maildelivery
This option is only available if you set mts to smtp.
servers: localhost
This option is only available if you set mts to sendmail/smtp or sendmail/pipe.
sendmail: /usr/sbin/sendmail
pophost:
A few words on locking: nmh has two main uses for locking: locking the mail spool during mail incorporation, and locking metadata files (sequence files, the context) during updates. These locking methods can be configured separately from each other.
For locking the mail spool, the spoollocking entry in mh-tailor(5) will control the locking algorithm to use when inc incorporates mail from the spool file. If no entry is given, a default based on the operating system type will be chosen.
For locking all other files, the datalocking entry in mh-profile(5) controls the locking algorithm used for all other file access. If no entry is given, the fcntl lock method will be chosen.
If you do not wish to use kernel-based locking, dot locking is an option available. If “--enable-lockdir=directory” is not specified at build time, lock files will be created in the directory where the file being locked resides. Otherwise, lock files will be created in the directory specified by “--enable-lockdir”.
Prior to installing nmh, you should see how locking is done at your site, and set the appropriate values.
None
As listed above. The path of the mail transport configuration file can be changed with the MHMTSCONF environment variable and augmented with the MHMTSUSERCONF environment variable, see mh-profile(5).
Failure to open any mail transport configuration file is silently ignored. Therefore, it's best to avoid dynamic creation of such a file with the intent of use via the MHMTSCONF or MHMTSUSERCONF environment variables. If such use is necessary, the ability to successfully open the file should first be verified.
2017-02-19 | nmh-1.8-RC2 |