In the article Fundamentals of the FreeBSD Shell, we discussed the change to FreeBSD 14’s default root shell. Another major update is the introduction of a new default Mail Transport Agent (MTA).
As the name suggests, an MTA transfers email between mail servers—without MTAs, you would not be able to send email to anyone at a different domain than your own. Sendmail has faithfully served this purpose on most Unix and Unix-like operating systems since the early days of email. For a long time, Sendmail was considered the definitive mail server software, and it has a comprehensive feature set to go with that. In FreeBSD 14, the default MTA is being replaced with DragonFly Mail Agent (DMA).
FreeBSD 14's New Minimalist MTA
One might wonder why this matters—after all, most people eschew local mail facilities in favor of hosted webmail services like Gmail. However, many components on a Unix system require lower-level interfaces for sending mail. For example, cron will send the output of jobs it invokes as an email. In FreeBSD Periodic Scripts, we talked about the periodic scripts, which also use email for sending their results. In short, the FreeBSD base system needs basic email functionality.
One problem with Sendmail is that it goes far beyond the basic functionality that is required. Lots of features mean lots of places for security holes to hide, and Sendmail has had more than its fair share of issues over the years. With Sendmail included in FreeBSD base, these issues become a concern for anyone running FreeBSD.
Challenges of Sendmail and the Shift to DMA
Even among people wanting to run a full-featured mail server, Sendmail long ago ceased to be the most popular choice, with alternatives such as Postfix, Exim, OpenSMTPD, and Qmail also in wide use. Sendmail is also notorious for the arcane syntax used to configure it. The configuration file typically needs to be quite extensive, often generated with the m4 preprocessor. m4 is a tool that many veteran Unix sysadmins have a love-hate relationship with.
DMA comes from the DragonFly BSD project and was written specifically to encompass just the functionality that is needed on a minimal system. So, local software can generate emails, and DMA will either deliver them locally or pass them on to a remote mail server—known as a smarthost or sometimes a relayhost. What it lacks is the ability to act as a smarthost itself, accepting mail from other systems along with all the modern malware and spam prevention mechanisms that would entail.
In the past, a common choice for jails and minimal systems was to install sSMTP from ports or packages, and the FreeBSD Handbook includes clear instructions for setting up sSMTP. Unlike DMA, sSMTP doesn't support local delivery.
Setting Up DragonFly Mail Agent (DMA)
DMA has been available in the base system since FreeBSD 11, so there is no need to wait any longer if you'd like to use it. We’ll provide an overview of the process here. For more detailed instructions, the FreeBSD Handbook offers excellent coverage on changing the Mail Transfer Agent.
First, you must disable Sendmail in /etc/rc.conf, and then update all the lines in /etc/mail/mailer.conf to use /usr/libexec/dma instead of Sendmail. (Software often expects to invoke Sendmail to send email, so other MTAs emulate Sendmail's interface.)
On FreeBSD, the various Sendmail commands—such as mailq, newaliases, and sendmail itself—are symbolic links to a program named mailwrapper. The mailwrapper utility consults the mailer.conf file to determine which command to run. Some interfaces, such as newaliases, are not particularly relevant to DMA. It does support mail aliases, but doesn't build a database of them.
Using a Smarthost
The next step is to configure DMA itself. The configuration file, /etc/dma/dma.conf relatively simple, with only a few values to adjust. These are essentially the same settings you need when configuring a mail program such as Thunderbird for outgoing mail.
By default, DMA will attempt to send mail not addressed to the local host directly to the designated receiving mail server for the recipient’s domain. In most cases, this feature of DMA is best avoided. Modern anti-spam measures impose strict controls to verify the host from which mail originates. Mail destined for external addresses must be relayed through the appropriate mail server for the source address.
DMA-Based Mail Configuration
The SMARTHOST configuration value specifies the name of an external mail server to which mail should be forwarded. Like other MTAs, such as Postfix, DMA will actually look up the DNS MX record for the hostname you specify, and try each of the hosts that returns. This allows for redundant setups with a backup server.
You may also need to set PORT, if the mail server doesn't use the default of TCP port 25, or your internet provide blocks outbound connections on port 25. 587 and 465 are common for mail servers that use TLS for encryption. For TLS, the SECURETRANSFER option is required and, in most cases, will be combined with STARTTLS. There are also options for setting the hostname DMA uses when identifying itself, which can be useful to ensure a fully qualified hostname is used.
If the smarthost requires a username and password for authentication, these are configured in a separate file, /etc/dma/auth.conf.
To test the setup, use the FreeBSD base system program mailx to create an email from the command line. Given just a recipient as a parameter, mailx will prompt you first for the message subject and then for the content of the message. After entering some minimal text to identify the test run, either press Ctrl-D or enter a line consisting of just a single period to complete the message. You should then be able to examine /var/log/maillog for details if it failed.
If the smarthost is temporarily unavailable, DMA will queue mail. Unlike Sendmail, DMA does not run as a persistent daemon and cannot automatically retry failed messages. If needed, create a cron job that runs /usr/libexec/dma -q periodically.
TLS Client Certificates
If your smarthost is a mail server you control, and you want a secure way to restrict and authenticate the client systems, TLS client certificates are a good choice. TLS is typically used with certificates for the server. In this case, it is useful to verify that clients are trusted. By setting the CERTFILE parameter to point to a .pem file, DMA will use that file when connecting to the smarthost. The .pem file needs to contain a certificate that has been signed by a certificate authority (CA) trusted by the smarthost. For your own mail server, this would usually be a CA you create yourself.
Local Delivery
If you leave either DMA or Sendmail in their default, unconfigured state, they will deliver mail locally for users on the system. Even with a smarthost configured, you must set the NULLCLIENT option to ensure that anything sent to a local user is passed on.
For capturing output from cron jobs and the periodic scripts you may decide that local delivery is preferable to filling up your normal mailbox. In this case, familiarity with basic command-line tools for reading mail is useful. The mailx command, introduced earlier, is perfectly adequate for the task of viewing output from a few automatic jobs.
After running mailx with no parameters, you may see output such as the following:
# mailx
Mail version 8.1 6/6/93. Type ? for help.
"/var/mail/root": 2 messages 2 new
>N 1 root@hostname Sat Jul 15 01:56 293/16873 "hostname daily security run output"
N 2 root@hostname Sat Jul 15 01:56 82/2925 "hostname daily run output"
&
To view a message, simply enter the number corresponding to the message you wish to view and press Enter. There are several single-letter commands available: d deletes messages, h repeats the list of message headers, n shows the next message, and ? prints help information. Finally, q exits back to your shell prompt. When you quit, the mails are transferred to a file namedmbox in your home directory. If you'd like mail for root to instead go to a different user, create an alias in /etc/aliases.
If you prefer a more user-friendly interface, TUI-style tools for reading mail, such as mutt, are available in ports. There are also more powerful tools, if you'd like to try reading all of your daily email from the command line, in addition to basic access to system messages. MH and its newer descendant nmh have been around for a long time and are very flexible. There's also mblaze, which draws inspiration from nmh but uses a more standard Maildir backing store.
Conclusion
The DragonFly BSD project has provided DMA as a lightweight MTA, unlike the full-featured alternatives such as Sendmail and Postfix. Making it the default on FreeBSD not only reduces the configuration burden for administrators but also limits the scope for security vulnerabilities. Most systems only need basic mail services, and where a fully functional MTA is needed, there is a good choice of them that can be installed from ports.
Embedded