Setting up Email Sending with Postfix

We have Linux servers that need to be able to send mail, but do not need to run an SMTP receiver.

Install the postfix and mailutils Debian packages on the Linux server.

DEBIAN_FRONTEND='noninteractive' apt-get install -y -q --force-yes postfix

If you do not do that, but do a regular apt-get, selecting "no configuration" will simplify these instructions, which have been handed down and successfully used for a couple of generations.

After you modify /etc/postfix/main.cf, be sure to run /etc/init.d/postfix reload, or the equivalent service command.

You must modify /etc/postfix/main.cf to ensure it includes something like:

myhostname = HOSTNAME.uwaterloo.ca
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = 
relayhost = mx.cs.uwaterloo.ca
# Duh, shouldn't relayhost imply a connection cache?
# http://www.postfix.org/postconf.5.html#smtp_connection_cache_destinations
smtp_connection_cache_on_demand = yes
smtp_connection_cache_destinations = $relayhost
smtp_connection_cache_time_limit = 60s
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = ipv4

Make sure the relayhost (mx.cs in this example) lists the server you've just set up in its list of mail clients (used to be in /software/sendmail/config/local/clients; for sendmail packages it will be /etc/mail/local-host-names ). While different references to the same host may work, the one used should be "generic" in nature, to allow for ease of changing the specific name in future by simply changing DNS.

Currently it seems the only reasonable choices are

• mx.cs.uwaterloo.ca - for cs-general clients
• mx.student.cs.uwaterloo.ca - for cs-teaching clients

Hosts using such configuration do not necessarily need to be strictly in the same region as the named "relayhost", as long as the relayhost is configured to accept it.

Beware the following lines which might get put in the file by default, but which will cause harm. Remove or comment them out.

default_transport = error
relay_transport = error

Note also that setting the following to non-empty

mydestination = 

will result in an attempt to locally deliver mail for the given list of hostnames, which is not wanted if we have only the "smart" "mailhub" machines set up with procmail, spamassassin, general forwarding capability, etc.

In the recent past many machines were observed to be left with the following configuration which I think is installed by default.

inet_interfaces = all

That causes a server to appear on port 25 (SMTP). It appears the resulting Postfix server will never allow open relaying (which is a good thing), but it could annoy people doing security checks, and confuse other people.

Regarding...

smtp_connection_cache_on_demand = yes
smtp_connection_cache_destinations = $relayhost
smtp_connection_cache_time_limit = 60s
relayhost = mx.cs.uwaterloo.ca

While previously postfix versions might be encountered which would not run if given the above configuration, that no longer seems to be the case. However, it actually seems now that, in newer versions, something equivalent to the above is done as/by the default configuration. Although an attempt to formally verify that is not convincing, empirically clients without the above do not seem to have the tendency to get items stuck in the local mailq waiting for relaying.

     

Beware that postfix seems as a default to arrange that the current host is the email domain on outgoing messages. In general, that is inappropriate. You should make sure that domain is something for which a reply will work. Usually that is most easily done by putting @cs.uwaterloo.ca or @student.cs.uwaterloo.ca in /etc/mailname.

     

We have been assuming /etc/mailname contains the appropriate "domain" name. That should be ensured, so that mail appears to originate from a reasonably appropriate domain, and not an actual hostname of expected temporary existence (for instance, using the actual FQDN of the machine being configured is usually a bad idea).

Further notes

Empty relayhost

Use of an actual relayhost used to be standard, but it was never necessary so long as firewalling or other network restrictions did not prevent the server from evaluating the appropriate SMTP destination and connecting to it. Political developments are actually pushing us towards providing the service in this manner. At least until they fully suppress our mail entirely.

relayhost =

That will cause the configured host to evaluate mail destinations (via MX records) for itself, and attempt direct connections for delivery.

Enable TLS on outgoing mail

When doing direct SMTP connections to arbitrary (including off-campus) hosts, connections will by default be made in clear-text (with header and message data therefore potentially easily fully snoopable). To prevent that, the use of TLS should be specified.

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
smtp_tls_security_level = may
tls_random_source = dev:/dev/urandom
smtp_tls_loglevel = 1

The first portion sets up the necessary mechanics, and enables it for the incoming SMTP server (which is not actually used). The last portion enables TLS for outgoing connections ("may" handles the possible unfortunate need to talk to external receiving SMTP servers which for some reason do not implement TLS; perhaps we cannot negotiate a compatible cipher, for instance).

   

-- DawnKeenan - 29 Apr 2010
-- AdrianPepper - 2013-10-08
-- AdrianPepper - 2020-12-07
-- AdrianPepper - 2021-07-07