Sending messages to external recipient fail: SASL LOGIN authentication failed

1

Since March 23, messages to external recipients remain in the postfix queue (messages to addresses hosted on my box are ok).

My box:
MIAB v67
Ubuntu 22.04.4 LTS on a Contabo VPS

  • DNS resolution works
  • I rerun the MIAB setup
  • Looking at other similar incidents I changed inet_protocols from “all” to “ipv4”
  • I made sure the libsasl2-modules was installed
  • Tried adding “lmtp_destination_recipient_limit = 1” at the end of the config, but it didn’t help so I removed it

I’m desperate and about to get in trouble with my box’s clients (familiy members…) if I don’t figure this out very quicly, thank you in advance for your help!

/var/log/mail.log shows:

Mar 27 00:39:53 box postfix/submission/smtpd[24163]: warning: unknown[80.244.11.48]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Mar 27 00:39:53 box postfix/submission/smtpd[24163]: lost connection after AUTH from unknown[80.244.11.48]
Mar 27 00:39:53 box postfix/submission/smtpd[24163]: disconnect from unknown[80.244.11.48] ehlo=1 auth=0/1 rset=1 commands=2/3

Here’s my /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)
smtpd_banner=$myhostname ESMTP Hi, I’m a Mail-in-a-Box (Ubuntu/Postfix; see https://mailinabox.email/)
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
delay_warning_time=3h

readme_directory = no

See Postfix Backwards-Compatibility Safety Net – default to 3.6 on

fresh installs.

compatibility_level = 3.6

TLS parameters

#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_cert_file=/home/user-data/ssl/ssl_certificate.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_key_file=/home/user-data/ssl/ssl_private_key.pem
smtpd_tls_security_level=may

smtp_tls_CApath=/etc/ssl/certs
#smtp_tls_security_level=may
smtp_tls_security_level=dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

#smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_relay_restrictions=permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
myhostname = box.bandelier.eu
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
#mydestination = $myhostname, vmi339775.contaboserver.net, box.bandelier.eu, localhost.bandelier.eu, localhost
mydestination=localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit =sudo vim /etc/postfix/main.cf 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4
smtp_bind_address=93.104.212.220
smtp_bind_address6=
maximal_queue_lifetime=2d
bounce_queue_lifetime=1d
smtpd_tls_auth_only=yes
smtpd_tls_dh1024_param_file=/home/user-data/ssl/dh2048.pem
smtpd_tls_protocols=!SSLv2,!SSLv3
smtpd_tls_ciphers=medium
tls_medium_cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA
smtpd_tls_exclude_ciphers=aNULL,RC4
tls_preempt_cipherlist=no
smtpd_tls_received_header=yes
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_mandatory_ciphers=high
tls_high_cipherlist=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
smtpd_tls_mandatory_exclude_ciphers=aNULL,DES,3DES,MD5,DES+MD5,RC4
smtp_tls_protocols=!SSLv2,!SSLv3
smtp_tls_ciphers=medium
smtp_tls_exclude_ciphers=aNULL,RC4
smtp_dns_support_level=dnssec
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_mandatory_ciphers=high
smtp_tls_CAfile=/etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel=2
virtual_transport=lmtp:[127.0.0.1]:10025
smtpd_sender_restrictions=reject_non_fqdn_sender,reject_unknown_sender_domain,reject_authenticated_sender_login_mismatch,reject_rhsbl_sender dbl.spamhaus.org
smtpd_recipient_restrictions=permit_sasl_authenticated,permit_mynetworks,reject_rbl_client zen.spamhaus.org,reject_unlisted_recipient,check_policy_service inet:127.0.0.1:10023
message_size_limit=134217728
smtpd_sasl_type=dovecot
smtpd_sasl_path=private/auth
smtpd_sasl_auth_enable=no
smtpd_sender_login_maps=sqlite:/etc/postfix/sender-login-maps.cf
smtputf8_enable=no
virtual_mailbox_domains=sqlite:/etc/postfix/virtual-mailbox-domains.cf
virtual_mailbox_maps=sqlite:/etc/postfix/virtual-mailbox-maps.cf
virtual_alias_maps=sqlite:/etc/postfix/virtual-alias-maps.cf
local_recipient_maps=$virtual_mailbox_maps
smtpd_milters=inet:127.0.0.1:8891 inet:127.0.0.1:8893
non_smtpd_milters=$smtpd_milters
milter_default_action=accept
smtpd_data_restrictions=reject_unauth_pipelining
lmtp_destination_recipient_limit = 1

2

The IP address “80.244.11.48” from your mail.log is listed as an “Abuser” here, so I don’t think that it is related to the Postfix queue problem you have.

Regarding your outgoing mail stuck in queue, you can try running “postqueue -i [queue_id]” on one of the emails in queue (to get emails “queue_id” run “postqueue -p”).
Then check your mail.log to see if there’s an error logged in the there.
I think it will give you a more accurate picture of what is holding your outgoing email in queue.

P.S.
If the email was sent without any errors, you can repeat the process for other emails in the queue.

3

@solomon Thank you very much for answering my call for help and for the clarification. Unfortunately resubmitted messages still don’t reach their destination.

I have a hard time sorting out messages in mail.log because even though I have a dozen active (but precious) users, the logging is extremely busy (a lot of those SASL authentication errors and also - I assume - Postfix constantly retrying to post queued messages).
I believe that the relevant lines when I submit a queued job are as following:

Mar 27 21:34:48 box postfix/qmgr[43896]: 99BCB280249: from=jonathan@bandelier.org, size=766, nrcpt=1 (queue active)
Mar 27 21:34:48 box postfix/smtp[200030]: initializing the client-side TLS engine

The message I get when printing the queue might be more relevant:

99BCB280249 766 Wed Mar 27 00:08:18 jonathan@bandelier.org
(delivery temporarily suspended: conversation with smtp-inbound1.duck.com[52.146.152.212] timed out while receiving the initial server greeting)
calagan@duck.com

Thanks in advance for your continued help

4

Additionally, I tested a simple telnet on port 25 of smtp-inbound1.duck.com and indeed, from my MIAB box, I am not getting any greeting message, whereas on another Contabo VPS, I am getting one:

From my MIAB box:

jonathan@box:~$ telnet smtp-inbound1.duck.com 25
Trying 52.146.152.212…
Connected to smtp-inbound1.duck.com.
Escape character is ‘^]’.

From my other Contabo VPS:

jonathan@cloud:~$ telnet smtp-inbound1.duck.com 25
Trying 52.146.152.212…
Connected to smtp-inbound1.duck.com.
Escape character is ‘^]’.
220 smtp-inbound1.duck.com ESMTP DuckDuckGo is ready

Same result with other servers, like GMaills’ alt4.gmail-smtp-in.l.google.com or Yahoo’s mta5.am0.yahoodns.net: no greeting on the MIAB box, a greeting on the other Contabo VPS

I thought it might be a firewall issue, but no relevant log entries in ufw.log; I even disabled it for a few seconds, but no way to get any greeting message

5

I’ve looked at the “TLS parameters” you pasted and compared it with my main.cf settings.
I didn’t find the following line in my settings:
smtp_tls_CApath=/etc/ssl/certs

This line is marked out:
myorigin = /etc/mailname

This line seems strange, maybe a mistake,
mailbox_size_limit =sudo vim /etc/postfix/main.cf 0
In my settings it is as follow:
mailbox_size_limit = 0

The following lines are present in my main.cf file but not in your pasted TLS parameters:
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_discard_ehlo_keywords=“chunking, silent-discard”

Maybe the problem you’re facing is just a few missing lines in main.cf.

6

Thanks again for your help.
My main.cf was indeed messed up, but unfortunately applying the changes you proposed did not resolve the issue.

I then decided to apply the “Things went horribly wrong” chapter from the maintenance guide, backed up my data, formatted my box to re-install MIAB from scratch and restored my data.

I am back to a functioning server with an empty mail queue, while still a bit frustrated not being able to pinpoint the exact error.

From that adventure, I learnt two things:

  • duplicity works great, but it’s not configured in MIAB to backup config files, so you won’t find a postfix/main.cf in your backups
  • It’s not enough to have 100% all green System Status Checks in the Web interface to confirm your MIAB is functioning properly, an occasional look in the postfix queue via Munin or the postqueue -p command could be necessary