Postfix smtpauth and clients without imap/pop-auth

Clients that does not support SMTP authentication via imap or pop

Full documentation of a postfix setup is also available at Tornevall Networks at https://docs.tornevall.net/x/JQDpAw – for updates, I suggest that you read there first.

This text is written in october 2020 after ripping my hair of my head off for a while. What I did not think of, during the first round of installation, was that there will be non standard clients that won’t do a pop/smtp-auth before entering the SMTP out. For example, Postfix, straight out of the box – where you want to relay from postfix to postfix via an authenticated user. With the solution above, there might happen things that you do not want. The error message below for example, is quite common but very much unanswered in different kinds of forums. Most of the idiots^H^H^H^H^Hposts are relating their problems to dovecot, cyrus and different kind of solutions that in the end seem to be database driven. This is not bad, it’s just a little bit stupid since you suddenly rely your systems on yet another point of failure: The database. And the more crap you implement, the harder it will be to find the failing point.

warning: SASL authentication failure: unable to canonify user and get auxprops

However, the solution may be much simpler than you think in this case. It was first, when I stumbled over theURLs below URLs, I realized that some settings are just misconfigured with the sasl authentication daemon.

As the first step after finding the entire solution, I tried to change the auth mechanism to a shadow based solution as I don’t like extra databases to just make authentication work. This however failed, and since the server itself is in a production state I have to stick with the db solution for a while (because I actually don’t know if this have effect on other working systems currently in operation).

The solution?

Well, since at least one of the sites are mentioning chrooted files, saslauthd won’t read the ”real” /etc/sasldb2, since it’s not really in /etc – the real file resides in /var/spool/postfix/etc, and requires only one thing: That you create it and put it there and making the sasl user the group owner of the file. This is how it should look.

# ls -l /var/spool/postfix/etc/sasldb2
-rw-r----- 1 root sasl 12288 Oct 4 12:00 sasldb2

The only backside of this is that you may have another load of users in another location /etc/passwd, that still won’t be able to authenticate as long as they are not added to sasldb2.

The documented problem URLs

https://serverfault.com/questions/409828/cant-get-sasl-auxprop-sasldb-working-with-postfix-ubuntu-12-04
https://annvix.com/enabling_sasl_in_postfix