SASL passwords are created with the container's hostname as domain about docker-postfix HOT 10 CLOSED

Hi,

thanks for this detailed report. You are, in fact, correct. The documentation was not clean enough on that part.

The latest commit to master should have this fixed. Please do kindly test and let me know if you run into any additional issues.

from docker-postfix.

Hi, I haven't build this yet but had a quick look through the source and will test next weekend.

I think the bad users handling is unnecessary, i.e. you can always pass a sensible domain default, and the user can override this if desired:

/tmp # echo test | saslpasswd2 -p -c -u example.com bokysan
/tmp # echo test | saslpasswd2 -p -c -u example.com [email protected]
/tmp # sasldblistusers2
[email protected]: userPassword
[email protected]: userPassword

Also, it would be helpful to call sasldblistusers2 at the end to log the added user accounts.

from docker-postfix.

I think the bad users handling is unnecessary, i.e. you can always pass a sensible domain default, and the user can override this if desired:

The problem is legacy. If users are already using it as-is they won't notice the change and will complain why authentication stopped working all of a sudden.

from docker-postfix.

Also, it would be helpful to call sasldblistusers2 at the end to log the added user accounts.

Generally not the best idea to log the passwords on the console. True, they are provided as environment variables, but in Kubernetes, for example, they can read from Secrets so they are semi-hidden, at least.

Logging them directly into console at startup seems really bad to me.

from docker-postfix.

sasldblistusers2 doesn't print the actual passwords, only the literal string userPassword. It took me over an hour to figure out that SASL authentication wasn't expecting just user, but something very different.

And I don't see how your current solution is any different with regards to backwards compatibility. If someone currently relies on SMTPD_SASL_USERS="user:pass" becoming user@<containername>, your change will break this, too. And they don't deserve any better...

With SMTPD_SASL_USERS="[email protected]:pass", the result will be identical to previous releases, ie. it doesn't matter what you specify with -u, or if you use -u at all.

You can test both with the example I gave you earlier today ;)

from docker-postfix.

root@6eafbb376f55:/tmp# sasldblistusers2
root@6eafbb376f55:/tmp# echo test | saslpasswd2 -p -c bokysan_without_domain
root@6eafbb376f55:/tmp# echo test | saslpasswd2 -p -c -u example.com bokysan_without_domain
root@6eafbb376f55:/tmp# echo test | saslpasswd2 -p -c -u example.com [email protected]
root@6eafbb376f55:/tmp# sasldblistusers2
[email protected]: userPassword
[email protected]: userPassword
bokysan_without_domain@6eafbb376f55: userPassword

from docker-postfix.

Re: the Debian image, the latest commit made it work again with SMTPD_SASL_USERS now.

There's another issue though:

cp: '/etc/localtime' and '/var/spool/postfix/etc/localtime' are the same file

I think it's the repeated copy here:

(ignore the original post, /var/spool/postfix/etc was a file in my mounted volume!?).

from docker-postfix.

I've also rebuild master using alpine:latest - no major issues. Occasionally the following appears in the log file, but I can't reproduce this.

postfix/postfix-script[301]: warning: group or other writable: /etc/postfix/./makedefs.out

Another thought: switching between base images and keeping the same volume for /var/spool/postfix might be a source of spurious errors. I've seen this in other issues and experienced them myself. Wouldn't it be a good idea to zap any existing etc and usr directories when setting up the chroot? Or at least putting a warning in the docs and examples?

from docker-postfix.

Do you want a pull request? ;)

That would be nice, yes. Thank you. 🙂

from docker-postfix.

Another thought: switching between base images and keeping the same volume for /var/spool/postfix might be a source of spurious errors. I've seen this in other issues and experienced them myself. Wouldn't it be a good idea to zap any existing etc and usr directories when setting up the chroot? Or at least putting a warning in the docs and examples?

Agreed. When I created alternate images I did not imagine that people would be switching between them back and forth. But your tool does get used in ways you've never expected. When starting you do get a warning but it would be prudent to add to docs that you should be doing this only if you really know what you're doing.

I'm against deleting anything, though - this is not something you'd expect an image to do and can come back and bite you in the a**. If anything I'd opt for killing the image and letting the user deal with this on his own.

I'll open another ticket on the topic if I just don't fix it in one commit.

from docker-postfix.