0

Following the Ubuntu's official guide Install and configure Postfix, when I run

telnet localhost 25

I get

Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Connection closed by foreign host.

When I look into the logs I get

$ sudo tail /var/log/mail.err Dec 7 11:38:17 <host> postfix/smtpd[8477]: fatal: no SASL authentication mechanisms

The above example is running in a virtual machine, but the same happens in a server in the cloud, and running telnet remotely to the domain. (I tried to replicate the process in the VM to see if I could spot what happens more easily).

I've read every post, blog, article, old and new, tried every configuration I could think of, and yet the error persists. I can't figure what is wrong. My configurations:

/etc/postfix/main.cf

# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # See http://www.postfix.org/COMPATIBILITY_README.html -- default to 3.6 on # fresh installs. compatibility_level = 3.6 # TLS parameters smtpd_tls_cert_file = /etc/ssl/certs/server.crt smtpd_tls_key_file = /etc/ssl/private/server.key smtpd_tls_security_level = may smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = <host> alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = <host>, <host>.local, <host>, localhost.localdomain, localhost relayhost = mynetworks = 127.0.0.0/8 [::1]/128 [::ffff:127.0.0.0]/104 [::1]/128 192.168.30.0/24 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all inet_protocols = all home_mailbox = Maildir/ smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous,noplaintext smtpd_sasl_tls_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_sasl_auth_enable = yes smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination smtp_tls_note_starttls_offer = yes smtpd_tls_loglevel = 4 smtpd_tls_received_header = yes

/etc/dovecot/conf.d/10-master.conf

service auth { unix_listener auth-userdb { #mode = 0666 #user = #group = } # Postfix smtp-auth unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } # Auth process is run as this user. #user = $default_internal_user }

The SSL files in the VM I created following the official guide Security - Certificates. In my cloud server I tried with Let's encrypt/Certbot files. I added them in the /etc/dovecot/conf.d/10-ssl.conf file

ssl_cert = </etc/ssl/certs/server.crt ssl_key = </etc/ssl/private/server.key

I restarted both Postfix and Dovecot services after each change in configuration. The services state:

Postfix

● postfix.service - Postfix Mail Transport Agent Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2023-12-07 12:26:07 UTC; 9min ago Docs: man:postfix(1) Process: 3362 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 3362 (code=exited, status=0/SUCCESS) CPU: 1ms dic 07 12:26:07 <host> systemd[1]: Starting Postfix Mail Transport Agent... dic 07 12:26:07 <host> systemd[1]: Finished Postfix Mail Transport Agent.

Dovecot

● dovecot.service - Dovecot IMAP/POP3 email server Loaded: loaded (/lib/systemd/system/dovecot.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2023-12-07 12:26:08 UTC; 12min ago Docs: man:dovecot(1) https://doc.dovecot.org/ Main PID: 3372 (dovecot) Status: "v2.3.16 (7e2e900c1a) running" Tasks: 5 (limit: 2220) Memory: 3.1M CPU: 44ms CGroup: /system.slice/dovecot.service ├─3372 /usr/sbin/dovecot -F ├─3373 dovecot/anvil ├─3374 dovecot/log ├─3375 dovecot/config └─3381 dovecot/stats dic 07 12:26:08 <host> systemd[1]: Starting Dovecot IMAP/POP3 email server... dic 07 12:26:08 <host> dovecot[3372]: master: Dovecot v2.3.16 (7e2e900c1a) starting up without any protocols (core dumps disabled) dic 07 12:26:08 <host> systemd[1]: Started Dovecot IMAP/POP3 email server.

I followed the Troubleshooting section in the guide. I tried many permutations, but nothing works, and the logs don't give any detail I can work with.

The question is already too long, and as I tried so many things I prefer not to make it longer, please ask in the comments and I will edit adding relevant information if needed. Maybe I'm missing something very basic.

Improve this question
1
  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Unix & Linux Meta, or in Unix & Linux Chat. Comments continuing discussion may be removed. Commented Dec 22, 2023 at 20:24

2 Answers 2

Reset to default
2

I propose to use the excellent postfix defaults. Rather follow official guides and create a minimal (and commented) configuration. The defaults for the above parameters are

postconf -d | grep -E "smtpd_sasl.*security_options" smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
Improve this answer
1

The Ubuntu guide

One would expect from the Ubuntu official guide that following the steps S will give the result R that can be tested with T, as that's how the guide is presented.

After doing S → R → T, my test failed, hence my confusion and the question posted here.

But, it happens that following S doesn't result in R:

The guide gives this configuration in S:

... sudo postconf -e 'smtpd_sasl_security_options = noanonymous,noplaintext' ...

Notice the noplaintext.

The guide then says "Outcome of initial configuration":

... smtpd_sasl_security_options = noanonymous ... smtpd_tls_auth_only = no

Notice there's no noplaintext, and also the smtpd_tls_auth_only = no that is not in S and is not in the default postfix configuration file (version 3.6.4).

So it happens that testing with telnet as suggested in the guide won't work if noplaintext is set, because it means that the communication must happen securely, and telnet doesn't support SSL.

From www.postfix.org/SASL_README

A more sophisticated policy allows plaintext mechanisms, but only over a TLS-encrypted connection:

/etc/postfix/main.cf: smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous

Tests:

  • With smtpd_sasl_security_options = noanonymous connecting with telnet will work:

    telnet <domain> 25

  • With smtpd_sasl_security_options = noanonymous,noplaintext connecting with telnet won't work.

  • With smtpd_sasl_security_options = noanonymous,noplaintext and smtpd_tls_auth_only = yes connecting with openssl will work.

    openssl s_client -starttls smtp -connect <domain>:25

  • With smtpd_sasl_security_options = noanonymous,noplaintext and smtpd_tls_auth_only = no connecting with openssl won't work.

In summary, the Ubuntu guide is broken, at least for Ubuntu server 22.04, following S won't result in R so T will fail.

All this is acknowledge in the forum of the guide, even that the it should be rewritten, under the link Help improve this document in the forum (an account must be created to access). Here's a comment of one of the contributors:

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.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.