This is a document copied from https://www.tornevalls.se/2019/08/12/the-postfix-maildir-guide/
...
Clients that does not support SMTP authentication via imap or pop
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 posts 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.
| No Format |
|---|
warning: SASL authentication failure: unable to canonify user and get auxprops |
...
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 - that you create it and put it there and making the sasl user the group owner of the the -file. This is how it should look.
...
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.
Example of how to create it "properly" first time:
| Code Block | ||||
|---|---|---|---|---|
| ||||
#> saslpasswd2 -c nisse
Password:
Again (for verification):
mv /etc/sasldb2 /var/spool/postfix/etc |
The documented problem URLs
...