MH-TAILOR(5)
π MH-TAILOR(5) π
okay bestie, welcome to the manual page for mh-tailor, aka mts.conf β the mail transport configuration for the nmh message handler. this is a File Formats Manual situation, so grab a lil snack and let's get into it π
β¨ NAME β¨
mh-tailor, mts.conf β mail transport configuration for nmh message handler π¦
πΈ DESCRIPTION πΈ
so the file /etc/nmh/mts.conf is where you define all the run-time options for the nmh programs that interact (in some form, bestie, some form) with the message transport system. right now those user programs are: ap, inc, msgchk, post, rcvdist, and rcvpack. that's the whole squad π
each option goes on a single line, one per line, no multitasking. blank lines? ignored. lines that start with #? also ignored, they're just vibes. now here's every option, its default, and what it actually means:
mts:β which mail transport method to use. the three acceptable options aresmtp(which is the default, she's the main character π),sendmail/smtp, andsendmail/pipe.
if you use smtp, this enables a direct SMTP interface in nmh. when sending mail, instead of handing the message off to the mail transport agent, post will open a socket connection to the mail port on the machine specified in the servers entry. it's giving direct communication, no middleman β¨
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. and for backward compatibility, sendmail/smtp can be abbreviated to just sendmail. cute right?
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. so like, it's the quirky legacy one, know what you're getting into π
localname:β the hostname nmh considers local. it should typically be a fully qualified hostname. if this is not set, depending on the version of Unix you're running, nmh will query the system for this value (e.g.uname,gethostname, etc.), and attempt to fully qualify this value.
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. sneaky but legit π
localdomain:β if this is set, a.followed by this string will be appended to your hostname.
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.). it's the backup plan, the safety net, the girly who shows up when the system flakes π«Ά
clientname:β this option specifies the host name that nmh will give in the SMTPHELO(andEHLO) command, when posting mail. if not set, the default is to use the host name that nmh considers local (seelocalnameabove). if this option is set, but empty, noHELOcommand will be given.
okay so, 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. like, read the room, basically π
systemname:β this option is only used for UUCP mail. it specifies the name of the local host in the UUCP βdomainβ. if not set, depending on the version of Unix you're running, nmh will query the system for this value. this has no equivalent in the nmh configuration file. ngl, very niche, very vintage πmmdfldir: /var/mailβ the directory where mail drops are kept. if this option is set, but empty, the user's home directory is used. this overrides the default value chosen at the time of compilation.mmdflfil:β the name of the mail drop file in the directory where mail drops are kept. if this is empty, the user's login name is used. this overrides the default value (which is empty).spoollocking: fcntlβ the locking algorithm to use when opening the mail drop. can be any one of the following:
fcntl dot flock lockf
maildelivery: /usr/libexec/nmh/maildeliveryβ the name of the system-wide defaultmaildeliveryfile. seeslocal(1)for the details.
π SMTP support π
this option is only available if you set mts to smtp.
servers: localhostβ a single hostname to be used when performing mail submission via SMTP. previous versions of nmh supported multiple hostnames forservers, but the current version of nmh only supports a single entry (the name is kept for backwards compatibility reasons). this can be overridden via the-serverswitch tosend(1). it is not possible to change the mail submission port number in theserversentry; see the-portswitch tosend(1)for this functionality. one host only, bestie, we're monogamous now π
π SendMail π
this option is only available if you set mts to sendmail/smtp or sendmail/pipe.
sendmail: /usr/sbin/sendmailβ the pathname to thesendmailprogram.
π¦ Post Office Protocol π¦
pophost:β the name of the default POP service host. if this is not set, then nmh looks in the standard mail drop areas for waiting mail, otherwise the named POP service host is consulted.
β File Locking β
a few words on locking, because this part is lowkey important: 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. two independent girlies, two independent settings π
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. fr fr, do your homework π
π FILES π
/etc/nmh/mts.confβ nmh mts configuration file
π PROFILE COMPONENTS π
None. that's it, nothing here, empty, a void, a clean slate β¨
π₯ SEE ALSO π₯
mh-mts(8), post(8) send(8)
πΈ DEFAULTS πΈ
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).
π BUGS π
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.
not me finding out it fails silently π that's the scariest kind of failure bestie, please verify your file actually opens before you rely on it π«Ά
and that's the whole page, you ate it, periodt π β¨ this was written for nmh-1.8, dated 2017-02-19 β go forth and configure your mail transport, you gorgeous nerd ππ¦
π¦ where this page comes from
- alpine 3.24: nmh-doc 1.8-r3 Β· BSD-3-Clause
- epel 10: nmh 1.8-3.el10_1 Β· BSD
- epel 9: nmh 1.8-1.el9 Β· BSD
- fedora 43: nmh 1.8-9.fc43 Β· LicenseRef-Callaway-BSD
- fedora 44: nmh 1.8-10.fc44 Β· LicenseRef-Callaway-BSD
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms