Donald's picture


I wonder if you can help? I have 2 wordpress appliances running, the current version and the previous version. I'm getting an issue with the current version detailed below:


When sending emails via a host I have a username and password configured in the SMTP Authentication And Encryption section of Postfix.


The postfix server v3.4.14 works fine but in the same configuration on the v3.5.13 postfix server I get the error  warning: SASL authentication failure: No worthy mechs found.

From Google and TK forum search most point to libsasl packages - which I have installed



        libsasl2-2 2.1.27+dfsg-2.1+deb11u1 Cyrus SASL - authentication abstraction library
        libsasl2-modules 2.1.27+dfsg-2.1+deb11u1 Cyrus SASL - pluggable authentication modules

        libsasl2-modules-db 2.1.27+dfsg-2.1+deb11u1

Cyrus SASL - pluggable authentication modules (DB)



Any sugestions?


Many Thanks



Jeremy Davis's picture

Are you 100% sure that your credentials are right? According to my googling, despite it not seeming very intuitive, there is a possibility that that error message can occur if authentication fails.

You do need the packages "libsasl2-2" & "libsasl2-modules" - bit I see that you already have those installed.

Next thing to do is to probably double check to see if you can manually authenticate. Use the tool 'testsaslauthd' - which may require the installation of the "sasl2-bin" package to get the required tool. I haven't got a system handy to test, so am going from a combo of memory and some quick googling. As such there is a possibility that it may not quite work as I'm hoping, but if it doesn't work, please post back and I'll set up a test system so that I can see if I can match your server.

Google suggests that the commands should look like this:

testsaslauthd -f /run/saslauthd/mux -s"smtp" -u"" -p"yourpass"

# OR

testsaslauthd -f /run/saslauthd/mux -s"smtp" -r"" -u"test" -p"yourpass"

Hopefully that might give some additional insight into the issue?

Another thing that might be worth checking is what packages are installed on the older, working system. Perhaps you are missing a plugin (that was previously bundled, but has since been pulled out into it's own package)? I'm not sure if that's the case, but it's possible.

FWIW you can find all directly related sasl packages like this:

apt search --names-only sasl2

Hopefully that at least gives you some additional info? Please post back regardless and we'll go from there.

Donald's picture

Hi Jeremy

Thanks for your update and suggestions. 

1. Credentials are definitely correct.

2. testsaslauthd - I tried the command above and several different variations to it, I get a file not found error. I checked the filesystem and there is no file or directory /run/saslauthd/mux. I searched the filesystem for mux files and there are none, I also had a look on Goggle and checked the suggestions from there - it's fairly sparse for testsaslauthd and the manual isn't of any help.

As the folder /run/saslauthd/ does exist I tried the command using this path - I got a connection refused error but I have the feeling this is a red herring and actually a problem with the command and the missing mux file. Do you have any idea how to create it? There in nothing in /etc/postfix/sasl folder either.

3. The sasl packages match between systems, the only difference being on the older server they are deb10 and the newer server deb11

4. Both are vanilla TK Wordpress VMs - I've not installed any of my own packages.

In the meantime I've had to relay smtp email from the new server to the older server which then sends out to my smtp mail replay provider, this will work for me in the short term but I'll need to try and find a fix.

I checked the documentation of my smtp providers and they state Encryption = STARTTLS and Authentication = Auth Login with is fairly standard.

Can you think of anything else?

Thanks for your help




Jeremy Davis's picture

Apologies on my slow response. I've been trying to finalize the v18.0 release and have been plagued with "death by 1000 papercuts".

Anyway, I am not super familiar with testsaslauthd myself (I just came across it when reading up on diagnosing postfix issues). Looking at the error message (file not found in /run - /run is tempfs - used for storing run state info), the name (has a 'd' as the last character - a common abbreviation for 'daemon') and inspecting the contents of the sasl2-bin package (I see a /etc/init.d/saslauthd - legacy sysvinit daemon script) I'm pretty sure that saslauthd needs to be running as a service for testsaslauthd to work. I/e/ try this:

systemctl start saslauthd

Then re-run the testsaslauthd test. It may not succeed, but hopefully it might give us some more insight into what is going wrong. FWIW as a bit of explanation/context to my conclusion, /run is a tempfs location when service sockets, etc are often stored (and wiped at shutdown and recreated when the services start). In retrospect, I probably should have noticed that and given you a heads up before.

As you note, the versions are essentially the same, so the only other thing that I can think of is a change that we made to our default config between v16.x & v17.x. I've just done a diff of the code and noted below the changes that we made (security hardening - a '+' prefix notes a line added, new lines that start with '#' - after '+' - are not ignored). TBH, I wouldn't have expected that to make significant difference, but perhaps?:

+# force TLS connections only - might break sending of mail so leaving disabled
+#postconf -e smtpd_tls_auth_only=yes
+# by default leave the snakeoil cert/key in place
+#postconf -e smtpd_tls_cert_file=/etc/ssl/private/cert.pem
+#postconf -e smtpd_tls_key_file=/etc/ssl/private/cert.key
+# despite name, accepts more bits (i.e. > 1024 bits)
+postconf -e smtpd_tls_dh1024_param_file=/etc/ssl/private/dhparams.pem
+postconf -e smtpd_tls_mandatory_protocols='!SSLv2, !SSLv3, !TLSv1, !TLSv1.1'
+postconf -e smtpd_tls_protocols='!SSLv2, !SSLv3, !TLSv1, !TLSv1.1'
+postconf -e smtpd_tls_mandatory_ciphers=medium
+# ciphers set by common/conf/turnkey.d/zz-ssl-ciphers
+postconf -e tls_medium_cipherlist="ZZ_SSL_CIPHERS"
+postconf -e tls_preempt_cipherlist=no

TBH, I wouldn't have thought so, but perhaps winding those back to defaults will resolve the issue? Although perhaps the cipher support is too tight?

FWIW the 'postconf -e tls_medium_cipherlist="ZZ_SSL_CIPHERS"' line will be updated at build time (so it will include a list of secure ciphers, rather than just "ZZ_SSL_CIPHERS").

You can get the default values for a postfix setting with 'postconf -d config-key'. E.g. like this:

root@tkldev5 ~# postconf -d smtpd_tls_dh1024_param_file
smtpd_tls_dh1024_param_file =

('smtpd_tls_dh1024_param_file' is empty by default).

So to reset to defaults, run these:

postconf -e smtpd_tls_dh1024_param_file=
postconf -e smtpd_tls_mandatory_protocols='!SSLv2, !SSLv3'
postconf -e smtpd_tls_protocols='!SSLv2, !SSLv3'
postconf -e smtpd_tls_mandatory_ciphers='medium'
postconf -e tls_medium_cipherlist='aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH'
postconf -e tls_preempt_cipherlist='no'

As I noted above, the only line that I would expect might have some impact is the cipherlist and/or if your mail provider is using an old (insecure) TLS protocol (technically anything lower that 1.3 is "broken", although 1.2 is still in common use and many older devices and legacy services don't support 1.3).

Apologies that I didn't think to check that out sooner. As a complete aside, here's how I found the differences:

git clone o turnkey
cd common
# list files changed between 16.x & 17.x that include 'postfix' or 'mail' in the filename
git diff --name-only turnkey/16.x turnkey/17.x | grep 'postfix\|mail'

The only result was conf/turnkey.d/postfix-local.

Add new comment