Comments (10)
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 Secret
s 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:
docker-postfix/scripts/common-run.sh
Line 157 in a26f85d
(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.
Related Issues (20)
- Log files are overflowing with milter messages HOT 1
- Can't create monitor on some nodes HOT 1
- Deployment doesn't use RELAYHOST for delivery HOT 4
- [Feature] Set healthcheck port in configuration options HOT 2
- Gmail not working? HOT 3
- /etc/default/locale: No such file or directory by cron calls HOT 2
- Using GMail as Relay: Way to generate tokens in README not working anymore HOT 2
- prometheus without k8s HOT 1
- Relaying through Mailgun for multiple domains and username/passwords HOT 1
- Rootless postfix? HOT 7
- Helm upgrade from 4.1.0 to 4.2.0 failing: mapping key "name" already defined HOT 4
- New Feature: Skip Health Check Logs option, Large Log files HOT 3
- A restrictive security context causes Read-only file system error HOT 2
- AWS SES Documentation Issue HOT 4
- LDAP lookup map support HOT 1
- Issues with smtpd_tls_security_level "may" setting HOT 6
- ARC (Authenticated Received Chain) HOT 1
- Can't send mail - all recipients were rejected HOT 1
- map uid/guid to different ids HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-postfix.