My postfix does not send AUTH PLAIN to the outgoing relay server. It must have worked a couple of days ago, but now I get "relay not permitted" bounce mails.

The mail system runs in an Alpine Linux VM using postfix, fetchmail and dovecot. Postfix uses the Cyrus SASL lib, not the dovecot one.

Relevant part of main.cf:

relayhost = [RELAY_HOST]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/mailsrv/etc/postfix/sasl_passwd
smtp_sasl_security_options =



I captured an outgoing session with tcpdump and no AUTH PLAIN is sent. I tested sending mail manually with telnet using the proper AUTH PLAIN line and it worked.

So my interpretation is, that postfix does not decide to use SASL / AUTH PLAIN at some point.

What could be the problem?

Permissions should be ok, postmap has been called, postfix restarted and reloaded, libsasl is installed and postfix reports to have been built with cyrus. I know it is a cliche, but the system used to work a couple of days ago. Could some certificate expiry be a problem here, which I don't see in the logs?

  • Does the server offer AUTH PLAIN in its EHLO response? (I've seen some servers which let the admin "disable" authentication but really just remove it from the offer list...) – user1686 Oct 19 '19 at 10:02
  • Actually I noticed in the meantime that the server shows AUTH PLAIN when I connect with telnet, but the tcpdump does not show it when postfix connects to it – Rainer Schwarze Oct 19 '19 at 10:51
  • Oh boy - postfix send HELO which does not produce the AUTH PLAIN lines, while I used EHLO in telnet... – Rainer Schwarze Oct 19 '19 at 10:54
  • What is the first line that is sent by the server (before HELO)? Many SMTP clients only use EHLO if the server's greeting declares ESMTP support. – user1686 Oct 19 '19 at 14:22
  • The first line sent by the server is 220 ******************************************************************************************. Maybe this is the reason why it suddenly did not work. The provider might have changed that. – Rainer Schwarze Oct 19 '19 at 14:47

postfix send HELO which does not produce the AUTH PLAIN lines

HELO is the original handshake command without any ability to negotiate extensions. Before the client can use SASL, it must send EHLO (extended-hello) and check that the server advertises the desired SASL mechanisms.

By default, many SMTP clients – including Postfix – send EHLO only when the word "ESMTP" appears in the server's greeting banner (e.g. 220 foo.example.com ESMTP Sendmail). Servers which don't support ESMTP are assumed to not support SASL either.

  • If the server's greeting is correct, make sure you did not enable the smtp_never_send_ehlo or smtp_pix_workarounds options by accident.

  • If the server's greeting is wrong, but it accepts EHLO nevertheless, you can force EHLO usage by enabling smtp_always_send_ehlo = yes in your Postfix configuration.

If you're managing the server, try to fix its greeting, as this likely also affects incoming message delivery from other domains – e.g. without ESMTP there is no opportunistic STARTTLS either.

For example, if the server is running Postfix as well, it must include "ESMTP" in the smtpd_banner option:

smtpd_banner = $myhostname ESMTP $mail_name

(It could also be that the connection goes through an anti-spam gateway which uses this method in an attempt to forbid STARTTLS usage – instead of simply removing it from the EHLO response, it tries to forbid EHLO itself.)

Note that usually port 25 is only meant for message reception (inbound delivery from other domains) – 587 or 465 are the ports meant for message "submission" (outbound from clients).

So if your Postfix is acting as a local client (because it has a relayhost and wants to use au­then­ti­ca­tion), it really ought to be connecting to the relayhost on port 587 instead.

Note that connecting to port 465 requires smtp_tls_wrappermode = yes, as it uses TLS from the very beginning. (This is actually an advantage as it prevents firewalls from tampering with the hand­shake.)

When using port 587, TLS is optional (only activated using the 'STARTTLS' command), but you also really should enforce TLS usage if the server supports it. To do so, set smtp_tls_security_level = verify.

  • Thanks for all the information. Switching to port 587 solved my problem. As I have a new version of my mailserver setup in the pipeline, I'll certainly take care of TLS. – Rainer Schwarze Oct 19 '19 at 15:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.