Install and configure Postfix

Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.

2 Likes

While postfix is the standard default for Ubuntu, there are numerous other options. I’ve found msmtp to be easy to set up and lightweight (if a bit slow, but that may just be me
)

Exim4 and Sendmail (now known as Proofpoint) are worth consideration, and also documented in this guide.

I dropped the section on mail-stack-delivery (deprecated and not working in Focal) and added a deprecation warning about it.

There’s also Let’s Encrypt, which I don’t think can be described as “commercial CA”.

Thanks, good point about Let’s Encrypt, I’ve added a mention to the article.

1 Like

@paride @bryce

Thanks. Nice Article.

We wanted a smtp (Gmail) only mail server for fail2ban, graylog etc services used for alerts. We wanted the hostname in email title. However changing anything on

mydestination = server1.example.com, localhost.example.com, localhost

doesn’t put hostname in email title. So we left mydestination field altogether with a simple main.cf

alias_maps = hash:/etc/aliases

relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_pwd
smtp_sasl_security_options = noanonymous
smtp_tls_CApath = /etc/ssl/certs
smtpd_tls_CApath = /etc/ssl/certs
smtp_use_tls = yes

It works. However it generates lots of entries on /var/log/mail.log

C345B88528D: to=<root@server-02.localdomain>, orig_to=<root>, relay=local, delay=0.25, delays=0.05/0.01/0/0.19, dsn=2.0.0, status=sent (delivered to mailbox)

Is there anyway we can stop these messages?

As far as I understand these are relaying mail on localhost. We do have server fqdn like server-02.example.com though we do not use it anywhere.

I found 2 issues when setting this up on a brand new Ubuntu Server 20.04 LTS:

sudo postconf -e ‘smtpd_sasl_security_options = noanonymous,noplaintext’

should be:

sudo postconf -e 'smtpd_sasl_security_options = noanonymous'

Also, when editing /etc/dovecot/conf.d/10-master.conf, you missed the closing ‘}’ on the

service auth {

section.

Once I changed those, I was able to successfully telnet from another server.

Thanks for the article :slight_smile:

2 Likes

@digital-pig thanks for taking the time to post about the changes you had to make! I’ve corrected the missing }.

As far as removing “noplaintext”, these configurations should allow plaintext mechanisms, but only over a TLS-encrypted connection. Did you also setup TLS or run into some other type of error?

1 Like

Actually I did not set up TLS. I was having some other issues getting graylog to send emails, so that may well be the cause of it. :smiley:

The sample man.cf file shown doesn’t match what the file looks like after running the previous commands. In particular, the mailbox_command variable isn’t set. The commands provided don’t even install procmail, so the sample file shown would probably generate errors.

1 Like

I agree with @digital-pig but I’d instead remove the tweaking of both smtpd_sasl_security_options and smtpd_sasl_tls_security_options to keep them at their default. Ensuring TLS is required for SASL would then be done with:

sudo postconf -e 'smtpd_tls_auth_only = yes'

The noplaintext setting caused problem to some user: LP: #1940603

3 Likes

This document should be more clear about how to configure postfix to accept communication on other ports, such as the submission port (587).
Also, if a mail server is put on the open Internet (i.e. not behind a firewall/filter), it really needs to have some sort of mechanism to filter and reject bad messages, although configuring these tools (e.g. SpamAssassin) may deserve a separate article.

What about adding a whole new section:
Postfix and LDAP?

While current guide tells about Dovecot Sasl auth it’s not enabled in final conf:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

These lines are missing. I’m fighting with Postfix + Dovecot SASL for 4 days already and cannot configure it :face_with_symbols_over_mouth:. This guide is complete disappointment so far.

Hello,
Did you run the commands in the SMTP Authentication section? The two first ones

sudo postconf -e 'smtpd_sasl_type = dovecot'
sudo postconf -e 'smtpd_sasl_path = private/auth'

should add

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

to /etc/postfix/main.cf or whatever your main config file is.

Yeap, I have these lines in my config and my build is broken. Log says

postfix/smtpd[2050092]: fatal: no SASL authentication mechanisms

all the time.

Do you have the TLS certificates in place?

Also, would you mind sharing the Ubuntu and package versions you are using to follow this guide? This would help us reproduce your case to check if there are any issues with the guide and help figuring out what the current issue is.

As mentioned in comment 11: Install and configure Postfix - #11 by sdeziel1. smtpd_sasl_security_options and smtpd_sasl_tls_security_options should be left untouched as otherwise you run into issues. Only setting smtpd_tls_auth_only = yes is simpler and safer IMHO.

Issue description

When using telnet 127.0.0.1 25, postfix will apply smtpd_sasl_security_options = noanonymous,noplaintext meaning that it will filter out PLAIN and LOGIN as they are are plain text mechanisms. Since dovecot was told to only enable those 2 (see auth_mechanisms), you have no other SASL mechanism to use
 hence the fatal: no SASL authentication mechanisms.

If however you connect with openssl s_client -connect 127.0.0.1:25 -starttls smtp you should see that PLAIN and LOGIN are both permitted because now you have an encrypted connection to the MTA so smtpd_sasl_tls_security_options = noanonymous applies. Since PLAIN and LOGIN are not annonymous, postfix doesn’t filter out any mechanism.

The noplaintext directive can be confusing because it sounds like something we want to prevent leaking credentials in plain text. However, PLAIN and LOGIN are meant to be used on top of TLS meaning there is no actual plain text on the wire.

Best current practices

I think the guide would need to be refreshed to follow best current practices. SASL auth should not be enabled on TCP/25, only on TCP/465 and TCP/587. It is best to leave port 25 for MTA to MTA (server to server) communication with opportunistic TLS and have users hit the smtps(TCP/465)/submission (TCP/587) ports where both TLS and authentication (SASL) are mandatory. Unfortunately, I don’t have time to do a rewrite :frowning_face:

2 Likes

I guess that was the case. Once I commented some of the smtpd_sasl options the error disappeared. If I understand correctly these few options are tightly connected to builtin Postfix SASL which disabled in my case in favour of Dovecot.

Postfix doesn’t implement SASL itself, it relies on Cyrus or Dovecot to do so. However, Postfix can filter out some mechanisms which is what smtpd_sasl_security_options and smtpd_sasl_tls_security_options are for.

smtpd_tls_auth_only = yes means that Postfix will propose SASL only when TLS is used by the client. In such case, plain text mechanisms are considered safe to use.

1 Like