MH-TAILOR(5)

πŸ“¦
version 1.8 Β· 4 versions
, in alpine 3.24, epel 10, epel 9, fedora 43, fedora 44

πŸ’– 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 are smtp (which is the default, she's the main character πŸ‘‘), sendmail/smtp, and sendmail/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 SMTP HELO (and EHLO) command, when posting mail. if not set, the default is to use the host name that nmh considers local (see localname above). if this option is set, but empty, no HELO command 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 default maildelivery file. see slocal(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 for servers, 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 -server switch to send(1). it is not possible to change the mail submission port number in the servers entry; see the -port switch to send(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 the sendmail program.

πŸ¦‹ 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