Setting up gmail as a relay host in postfix (without creating certificates)

When your linux box needs to send email (e.g., mail sent by a webpage, cron job output, etc), postfix can normally send the email directly to the recipient. However, if your ISP blocks port 25 outbound, or you want to keep a nice log of all outgoing messages, or want replies to arrive in your gmail account, this may not be ideal. One alternative is to use a Gmail as a relay host, i.e., postfix will basically pretend to be a gmail user, and send all mail through that account.

There are already a number of guides on the internet explaining how to set up postfix to relay outgoing email via Gmail:

These guides are excellent, I wouldn’t have been able to set up my server without them. However, they all demand the creation of CAs and self-signed certificates. If you don’t know what I’m talking about, then you’ve come to the right place! And if you do know what a CA is, then the purpose of this post is to point out that creating one is completely pointless in this case. So I’m proud to announce…

A simplified guide: setting up postfix to relay through Gmail

  1. Add the following lines to /etc/postfix/
    relayhost = []:587
    smtp_use_tls = yes
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_sasl_security_options = noanonymous
    # The following line is optional, but recommended (see below)
    smtp_tls_CAfile = /etc/ssl/certs/Equifax_Secure_CA.pem

    The last line is not necessary for postfix to successfully send messages, but it prevents ‘certificate verification failed’ warnings. I believe the /etc/ssl/certs/ directory is populated by installing OpenSSL.

  2. Place the following in a new file at /etc/postfix/sasl_passwd:
  3. Hide your password, and do some other magic stuff:
    $ cd /etc/postfix   
    $ postmap sasl_passwd          # creates sasl_passwd.db
    $ chmod 600 sasl_passwd sasl_passwd.db
  4. Restart postfix:
    $ service postfix restart      # this varies from system to system
  5. Test:
    $ echo 'It works' | mailx -s 'Test message'

What if doesn’t work — debugging

If you find that the recipient (e.g. doesn’t receive an e-mail, have a look in the log files. They’re located in different places depending on your configuration settings/distribution, but have a look in /var/log/mail.err, /var/log/maillog or /var/log/mail for starters. If the problem isn’t self-evident from looking at these messages, have a look at the official Postfix Debugging Howto for more help — or, leave a comment on this post!

Forwarding emails sent to usernames on your linux box

Utilities (e.g. at, cron, mdadm, etc) often send emails to the user if errors occur. The emails default to username@domain, where domain is the FQDN of the system. If you want these messages to be sent to a different address, create .forward files in the home directory of the relevant users:

# Forward messages for your user
$ echo > ~/.forward      
$ echo 'It works' | mailx -s 'Test message' username

# Forward messages for the root account
$ echo > ~root/.forward  
$ echo 'It works' | mailx -s 'Test message' root

Setting the ‘From’ name

Take with a grain of salt, there’s probably a better way than falling back on the sendmail emulation provided by postfix:

$ sendmail -F 'Name to Appear in From Field'

But wait, if we provide no certificate, will the emails be encrypted? [Optional!]

Yes. The email is encrypted; this can be confirmed with tcpdump. Encryption is accomplished using TLS (see Diffie–Hellman key exchange for an explanation of how two computers can communicate securely with no pre-arranged secrets or certificates.) Certificates are quite separate; they are used to verify whether the Gmail server is really the Gmail server, not some imposter. Of course, certificates and encryption are easily confused, as they’re always found together — there’s no point preparing a secure, encrypted channel to an imposter.

So, Gmail provides the certificate; and postfix can verify the authenticity of this certificate using file provided via smtp_tls_CAfile in step 1 above. The connection is then secured. Postfix then proves its identity using the plain old username and password (which is pretty much the only identity proof that we have at our disposal as a mere Gmail user) and the emails can be sent.

But why does postfix have configuration options to accept certificates and keys? What about configuration options starting with smtpd_ ? [Optional!]

The server/client distinction is very clear cut with many protocols, like HTTP — the web browser is the client, the web host is the server. Postfix is not so straightforward, because it acts as a middle-man — it’s a server when its receiving mail from the outside world, and then it’s a client when it relays that mail towards its final destination. So, postfix can be thought of as an SMTP server (smtpd) and client (smtp) combined. The configuration options are divided into smptd_* and smtp_* accordingly.

If we wanted our postfix server to accept mail on a secure connection from other computers on the network, and provide a certificate proving its authenticity to these other computers, then this is when these other options would become useful. But because we’re only accepting mail from localhost (for now), these options are completely irrelevant.