[#sndmlrcv]:

Receiving E-Mail via the program called “sendmail”

Yes, the irony is acknowledged: this section of text is about receiving E-Mail with a program that is named sendmail.

In OpenBSD, the sendmail program may be located at /usr/libexec/sendmail/sendmail while the standard location at /usr/sbin/sendmail may actually just be a link to mailwrapper.

Migrating from open source

The sendmail.org website and the sendmail.com website, and some others, have begun (at the time of this writing) to merge.

sendmail.com Open Source Website FAQ states “Open Source users will continue to be able to easily download the open source sendmail MTA just as they do today. We will however provide the entire Sendmail community with” ... “information and”... “products”. “This will include free evaluation copies to assist users in evaluating different products as well as tools for migrating from Open Source software to commercially supported products.”

(Markup, including a hyperlink, has been added to the quoted text. It was not part of the original quoted text.)

Moving from open source? Eebee jeebee!

OpenBSD FAQ 1: section about other software says the reason the operating system doesn't use qmail or djbdns is that “Neither program is what many Unix users ‘expect’ out of a mail or DNS application.” Hopefully OpenBSD doesn't apply this philosophy to OpenSMTPd (like this philosophy had been applied towards qmail and djbdns), because it would seem ironic if OpenBSD decided instead to endorse a company set and intent on moving people from open source to commercial solutions.

[#sndmktrf]: Allow access as needed
  • Check for any firewall rules that might block the content. (The section on firewalls may have more specific details: perhaps specifically the section about denying traffic. Make sure that the techniques in the “denying traffic” section are NOT being used, because the traffic needs to be not denied.
  • The sendmail program supports using TCP-Wrappers. If there is a possibility that usage of the sendmail program is being affected by TCP-Wrappers, then run:

    cat /etc/hosts.deny

    If SendMail, or more likely “ALL” supported programs, is listed on a line before the first period, then permission to use SendMail will need to be specifically added.

    cpytobak /etc/hosts.allow
     echo sendmail: ALL | sudo -n tee -a /etc/hosts.allow

    Pleasantly, if the SendMail software is already running, the change in the text file will take immediate effect. No additional steps are needed to make the text file's change matter.

    For more details about these files, see: OpenBSD Manual Page for hosts_access, from section 5 (file formats), OpenBSD Manual Page for hosts_access, OpenBSD Manual Page for hosts_access

Starting sendmail

Using OpenBSD's default configuration (as specified in the /etc/rc.conf file of that operating system) as a guide, here are some parameters to pass to the sendmail program:

[#sndmezgo]: Basic sendmail program execution
[#sndmlrun]: Running the sendmail software

Before trying to start the software, check if the mail queue is empty. Run:

sudo mailq

If there is any undelivered mail, taking care of that might be a worthwhile task to complete before making any changes to what E-Mail software is running. At the very minimum, knowing how much undelivered mail seems harmless. If you find that there's some outgoing E-Mails that are just waiting for an MTA to start, you may wish to check whether those E-Mails are likely to be desirable, or if they might be underable (spam). If those E-Mails are not desirable, don't start the sendmail program until they are removed. (Also, you'll likely want to check how they got created in the first place.)

Do not just assume that there are no E-Mail servers running just because one never got manually set up. (Perhaps especially Unix systems may, by default, have an E-Mail server listening to the loopback interface.) Check to see what software may be listening to the submission and SMTP ports.

netstat -na | grep "\.587"
 netstat -na | grep "\.25"
Freeing the ports

Stop any running E-Mail servers. For example, if SendMail is currently used:

sudo /etc/rc.d/sendmail stop

If that example command does not work well, see the more elaborate section on stopping the sendmail command.

(It may then be wise to re-run the netstat commands that were just shown, to confirm that the TCP ports are no longer being listened to.)

Note: this does not guarantee that sendmail won't be running on the system at all. In OpenBSD, there is a scheduled task that may run the sendmail. However, because that copy of the program does not reference an unwanted configuration file, there might be little need to remove that crontab entry at this time. (This entire topic gets described further in a section called removing sendmail from the crontab.)

Working with mailwrapper

Check if a /etc/mailer.conf file exists. If so, then the sendmail executable is probably actually the mailwrapper command. That is fine, and even preferred, but make sure that the executables referenced are in the correct locations.

cat /etc/mailer.conf

The desired “correct locations” generally means that each executable should be mapped to /usr/libexec/sendmail/sendmail except for the makemap entry which should map to /usr/libexec/sendmail/makemap

If all is well, go ahead and start SendMail.

sudo sendmail -L sm-mta -bd -C/etc/mail/sendmail.cf -q5m

Test if that is working: use a program to make a TCP connection to a port that is being listened to. For instance, using “ telnet localhost 587 ” will very often work. (For further details on how to fully perform the test of sending E-Mail, see: SMTP.)

If results look good, then make sure the program start automatically each time the system starts. Make sure to back up any files before making changes. (Using the the cpytobak program may be one simple method.) See: automatically started files which should provide a solution, and/or startup configuration files which might provide a classier solution.

Getting SendMail to auto-start when OpenBSD starts

The following is an example for OpenBSD:

cpytobak /etc/rc.conf.local
 echo sendmail_flags=\"-L sm-mta -C/etc/mail/sendmail.cf -q5m\" | sudo -n tee -a /etc/rc.conf.local

(With OpenBSD, the default startup process will start a mail server that only listens to loopback. This can be noticed by running, “ grep mta /etc/rc.conf ”. That mail server does not end up getting started if Having /etc/rc.conf.local sets the relevant variable to a different value.)

Especially if there was some other E-Mail server set up before, review the computer's startup procedures. (Make sure that no other E-Mail server is getting started).

Now, root and other users can receive E-Mail. This might not be what was wanted, so further customizations may be needed. This does, however, complete the section showing how to just get the software started using a desired *.cf configuration file.

Overview: how the recommended command line was chosen

As a starting point, consider the parameters used by the OpenBSD team. In /etc/rc.conf is the text:

# For normal use: "-L sm-mta -bd -q30m", and note there is a cron job
 sendmail_flags="-L sm-mta -C/etc/mail/localhost.cf -bd -q30m"
[#sndmlgtg]: sendmail's Logging-related tagging details

So OpenBSD typically runs this command shown in the second line. The -L sm-mta is described by OpenBSD's manual page for the sendmail command as being used to “Set the identifier used in syslog messages to the supplied tag.” When sendmail creates log entries, sendmail will make sure that this “identifier”/“tag” is part of the details that get placed into the log files.

This command line parameter does not even show up in another manual page for sendmail. So, on other operating systems, check on whether the version being used supports that command line parameter before trying to use it.

[#sndmcffl]: Configuration file

The “ -C” parameter specifies a configuration file. There should be no space between the “ -C” and the location of a configuration file to use. The default is /etc/mail/sendmail.cf (and is one of only a small number of files that uses a hard-coded default). OpenBSD's manual page for the sendmail command: section listing files shows no other hard-coded filenames supported by the SendMail binary. Another manual page for sendmail indicates that a PID file may also be hard-coded. So, details likely vary by implementation.)

Operating systems may use a different default configuration file, even if the SendMail binary does not have hard-coded support for some other filenames. For example, OpenBSD's default configuration will run the sendmail program with a reference to “ -C/etc/mail/localhost.cf ”. Such a reference a file named localhost.cf might not sound like it makes the most sense for a system that will be accepting mail from more systems than just localhost. Indeed, go ahead and specify another file.

(The syntax/contents of the configuration files are discussed further after this section about the command line syntax. Right now, this discussion is focusing just on the act of specifying the filename that gets used.)

Overview: this impacts running user

Specifying a configuration file is a great idea in OpenBSD: OpenBSD's Manual Page for sendmail says, “sendmail gives up any enhanced (set-user-ID or set-group-ID) privileges if an alternate configuration file is specified.” (Hypenation removed from quoted text.) Claus AΒmann's copy of a manual page for sendmail (which had remained unchanged for over a decade, last being updated July 26, 1998) says “Sendmail refuses to run as root if an alternate configuration file is specified.” Actually, not running sendmail as root might be a great idea!

[#sndmcavl]: Available sendmail main program configuration files

Customizing those files by changing the files directly is not recommended, as noted further by the proper process for How to update SendMail *.mc and *.cf configuration files.

A great general all-purpose choice that allows incoming and outgoing E-Mail may be to use the “ -C/etc/mail/sendmail.cf ” file. (That *.cf filename is mentioned by OpenBSD's Manual Page titled “afterboot” as an option for a file to be able to use to receive mail.)

However, there are other choices. Choices may be seen by seeing what /etc/mail/*.cf files exist. (These aren't necessarily recommended over the previously-mentioned /etc/mail/sendmail.cf, but details are provided for those who may have interest in pursuing further customizations, or in case there is a distribution (of operating systems, or perhaps simply a distribution of SendMail) that doesn't seem to have that specific sendmail.cf file pre-existing.)

OpenBSD's Manual Page titled “afterboot” describes the origin of some specific configuration files that are used as recommended defaults for that specific operating system. Users of other operating systems may want to check similar documentation. (In other words, try running: “ man afterboot ”. That will probably provide a bunch of information.)

Backgrounding

The “ -bd ” parameter uses Berkeley Interprocess communication (“Berkeley IPC”) to cause this program to become a transparent service. Actually, the term “background daemon” matches the letters of the command line parameter, so perhaps that is at least somewhat intentional.

There are some other options that could be used instead. To run the software in the foreground, for testing, use -bD. If sendmail needs to interact with standard input and output, which is what sendmail should do if sendmail is being referenced from the /etc/inetd.conf file used by the inetd “super server”, then use -bs (which implies having the effects of -ba).

[#sndmlqtm]: Queue updating (using sendmail)

Finally, the -q30m specifies how often saved mail gets sent from a mail queue. Perhaps 30 minutes was selected as an amount of time that won't cause as much hammering of a remote server. However, for testing purposes, it may make sense to shorten that value. e.g.: Consider using “ -q5m ”.

A typical system may, by default, have the queue processed regularly by using a cron job. Running “crontab -e” will show the superuser/system-wide cron jobs, and that may include a reference to running sendmail with some slightly different paramters, including -q without any parameters after it. If -q is not followed by a time, then the queue processing occurs once. Then, the background task doesn't re-schedule itself to repeat after a certain period of time. (However, such scheduling could still be occurring since a program such as cron may handle such scheduling.) (Information, based on text from an early pre-release version of this guide, points out, “if there is ever suspicion that messages are getting stuck in a queue, and need to be processed, one may use “sendmail -qf”. OpenBSD's manual page for the sendmail command has specific text for a -qf parameter, so -qf is not just some sort of combination of the functinality of the -q parameter followed by the functionality of the -f parameter.)

Out of all of the command line options just mentioned, the main thing that appearently needs some customizing is the configuration file that is being used.

As an example of the need to customize the chosen configuration file: OpenBSD's manual page for “afterboot” states: “OpenBSD ships with a default /etc/mail/localhost.cf file that will work for simple installations; it was generated from openbsd-localhost.mc in /usr/share/sendmail/cf.” ... “For the default installation, sendmail is configured to only accept connections from the local host and to not accept connections on any external interfaces.  This makes it possible to send mail locally, but not receive mail from remote servers, which is ideal if you have one central incoming mail machine and several clients.”

That sounds great and all, so that configuration file (which was just described) may be a fine default, but this doesn't really allow for any communication from remote E-Mail servers (or, perhaps more specifically, remote E-Mail servers that are trying to send incoming E-Mail). That isn't going to be the most useful starting point for a system which is expected to be receiving incoming E-Mails.

OpenBSD's manual page for “afterboot” “To cause sendmail to accept external network connections, modify the sendmail_flags variable in /etc/rc.conf.local to use the /etc/mail/sendmail.cf file in accordance with the comments therein.  This file was generated from openbsd-proto.mc.” (Note: the reference to the /etc/rc.conf.local is rather OpenBSD-specific, and may not be quite as applicable for other platforms that may be using the sendmail program. For other systems, identify the appropriate method by reviewing the section on automatically started files which should provide a solution, and/or startup configuration files which might provide a classier solution.)

Additional configuration files may be an option. (See: available sendmail configuration files.)

Mail acceptance
[#sndmldom]: sendmail's Supported Domains

SendMail may need to be informed about certain domain names in order to receive E-Mail at those domains. However, some domain names might not need to be manually specified (because SendMail can basically figure them out on its own).

OpenBSD's default /etc/mail/local-host-names (specifically quoting the OpenBSD's default /etc/mail/local-host-names file revision 1.1) has a comment saying, “You do not need to include the system hostname, localhost, the name(s)” “associated with any active network interface or a CNAME that points to one” “of those names.”. (The term “CNAME” is reference to DNS CNAME.) So, if the only host names to receive E-Mail are names that fit those descriptions, then this step is not needed at all (when using one of the main OpenBSD configuration files, and presumably this will also be true for most other computers as well).

The SendMail program will accept E-Mail to specific domains (e.g. a domain such as example.com). Additional domains can be recognized as acceptable E-Mail destinations if those domains are placed in a supporting configuration file. One such file is the /etc/mail/local-host-names file.

Another file that might exist, and which might also work, would be a /etc/mail/virtual-domains file. However, /etc/mail/virtual-domains might not initially exist, and may also be unsupported by default configuration file(s). (There is a method available to add support for the /etc/mail/virtual-domains file if desired.) Using /etc/mail/local-host-names may be the easier option if support for /etc/mail/virtual-domains hasn't been enabled yet.

This can be useful if the mail server is meant to serve multiple domains. Note that this doesn't really adjust how the mail is handled by a supported domain. It simply adds to which domains are accepting mail.

Unverified: Feel free to use internal domains as well.

cpytobak /etc/mail/local-host-names
 echo mail.example.org | sudo -n tee -a /etc/mail/local-host-names
 kill -HUP $(pgrep sendmail )

The following is simply informational. This may or may not be simpler than using virtuser. Feel free to experiment with the following method. For another method which has been used more extensively by the author of this text, see the section about virtuser.

  • MicroBSD Handbook: Sendmail (archived at the Wayback Machine @ Archive.org) is a fairly small page, giving quick description of what some various files do. If you're trying to do something, an example might be there.
  • Features says "virtusertable" is "A domain-specific form of aliasing, allowing multiple virtual domains to be hosted on one machine." This may serve some relatively complex needs of supporting multiple domains. (Supporting just one domain should also work with this same process: It would simply be a simpler case of this process.)

After sendmail is willing to accept E-Mail from all of the necessary domains that sendmail needs to support, the next step is to handle E-Mail delivery to get the received E-Mail into the desired mailbox(es). (To use the sendmail program to do this, see the section on Using SendMail as an MDA.)

[#rmsmmspq]: Remove from crontab

Disabling this probably is a good idea if a different SMTP server is about to be getting used. (If that is the plan, then definitely proceed with the directions mentioned in this section.)

Otherwise, this might still be a good idea to do anyway. Archive of Nomoa's “Mail Service” guide (perhaps similar to Nomoa's guide to sendmail) has stated, "Note: To complete the installation process, we need to take heed of the warning: and note there is a cron job from the /etc/rc.conf file." As that wasn't just a suggestion to note something somewhere, but is a warning, acting on this text is may be recommended.

However, why? This simply seems to be overwriting some sort of default behavior placed by the operating system and/or makers of the SendMail software. One would imagine that the design was intentionally placed. (Further research on this matter may be warranted.)

Having learned a little bit more about the subect, it seems the command may be designed to handle outgoing messages that are in a queue. Perhaps the reason for disabling this was because the examples on that site involved using SendMail as a running “daemon”/server. Also, the website makes references to “The Sendmail Operations Manual” and “The sendmail bat book”. It is not really very clear what warning Nomoa is referring to, when it simply says “we need to take heed of the warning” by noting the cron job's existance.

Anyway, here are the directions for carrying out this process, whether or not it is wisest to follow them:

crontab -e

(This command attempts to run the system's default program for editing text files. Specifically, the command will attempt to run $VISUAL if that variable is set, or $EDITOR if that variable is set.)

Locate the relevant line, which is near the top of the file. (This may be the first non-commented line, after a few variable initializations and more comments.) The line, after commenting, may look like this:

*/30 * * * * /usr/sbin/sendmail -L sm-msp-queue -Ac -q

Add a comment character (#) to the beginning of the line, which “comments out” (and thereby nullifies the effects of) the line.

# */30 * * * * /usr/sbin/sendmail -L sm-msp-queue -Ac -q

To better understand the line that was commented out: The */30 does mean to use a “step value” of 30, which causes the command to run every 30 minutes. (This is documented by the OpenBSD Manual Section 5 (File Formats): entry for the crontab file, which can be read by running the command “ man 5 crontab ”). The “ -L sm-msp-queue ” is related to tagging used for the log files used by the sendmail command.

The -q parameter for the sendmail command specifies how long of a delay to use. Since nothing appears after the The -q parameter, the delay is zero, so sendmail does its job instantly.

The -Ac says that sendmail should use the configuration file named submit.cfg

[#sndmrego]: Restarting sendmail software

In Unix, if the reason for the restart is just to re-load the configuration files, using the same configuration filenames that were used when sendmail started, then the following might work:

sudo /etc/rc.d/sendmail reload

or, if that doesn't work, this older variation may work:

sudo kill -HUP $(cat /var/run/sendmail.pid)

Otherwise, checking the queue first is a recommended practice (discussed further by the section on stopping the sendmail software). This may be as simple as running:

sudo mailq

Modern Unix operating systems can generally try this:

sudo /etc/rc.d/sendmail restart

If that fails, then stop the sendmail software and see the section on starting the sendmail software.

[#sndmlstp]: Stopping the sendmail software

OpenBSD Manual Page for OpenSMTPd (OpenBSD's smtpd) recommends making sure the mail queue is empty. Granted, that manual page is for a different E-Mail program. Also, the reason appears to be in case a different E-Mail server will be used in the future. (As a generalization, it seems that mail should usually not be left forever undelivered in the old queue.) Regardless of these observations, checking the queue does not seem like a bad stop to perform anyway.

Perhaps ways of doing that may vary, but one method may be to run the mailq command (with no parameters needed). (That method may work even if other E-Mail software is being used, perhaps using the mailwrapper command.) Since sendmail is what is being used, another way may be to verify that the /var/spool/mqueue/ folder has no contents.

In general, the preferred way to stop sendmail on modern operating systems will be to run:

sudo mailq
 sudo /etc/rc.d/sendmail stop

To kill the sendmail program, follow the general steps/guidelines for seeing what software is running and then adjusting what software is running. Here is a quick guide with some specifics that work in OpenBSD. (Users of other operating systems may need to vary this, using the more generalized information just referenced.)

Stopping the sendmail program in OpenBSD

If the following command:

ps -auxww | grep -i $( pgrep sendmail ) | grep -v pgrep

shows that sendmail is running, then run:

pkill sendmail
Some other operating systems
Some operating systems may not have the pkill command, but may have a similar command called killall. Such platforms may also not have pgrep, and ps may take a slightly different syntax (try removing the hyphen and/or characters starting from the end of the command line parameters that are passed to the ps program).
Starting the software
Start the software with the command line parameters which are desirable. (See the section on starting the sendmail software.)