docker-mailserver: [BUG] cannot send email, private/auth failed: permission denied

Miscellaneous first checks

I checked that all ports are open and not blocked by my ISP / hosting provider.
I know that SSL errors are likely the result of a wrong setup on the user side and not caused by DMS itself. I’m confident my setup is correct.

Affected Component(s)

smtpd / sasl

What happened and when does this occur?

Without any updates to the container, user credentials, or vps, I cannot send mail anymore.

I can still connect to the smtp ports (both 465 and 587), it’s just that it will get rejected. IMAP receiving of email also still works.

What did you expect to happen?

I expect the SMTP server to accept my login and allow me to send emails.

Also, it seems to complain about SASL, but that’s disabled for my server.

How do we replicate the issue?

Uhm, I find this a bit hard to say right now, but I would like to help debug and figure out what’s going on

DMS version

v11.3.1

What operating system is DMS running on?

Linux

Which operating system version?

Alpine 3.16.4

What instruction set architecture is DMS running on?

AMD64 / x86_64

What container orchestration tool are you using?

Docker

docker-compose.yml

`  mailserver:
    image: docker.io/mailserver/docker-mailserver:11.3.1
    restart: unless-stopped
    stop_grace_period: 1m
    hostname: mail.XXX.cloud
    ports:
      - "25:25"     # SMTP  (explicit TLS => STARTTLS)
      - "143:143"   # IMAP4 (explicit TLS => STARTTLS)
      - "465:465"   # ESMTP (implicit TLS)
      - "587:587"   # ESMTP (explicit TLS => STARTTLS)
      - "993:993"   # IMAP4 (implicit TLS)
      - "4190:4190" # user seive
    volumes:
      - ./data/dms/data:/var/mail
      - ./data/dms/state:/var/mail-state
      - ./logs/dms:/var/log/mail
      # borrow traefik log
      - ./data/traefik/acme.json:/etc/letsencrypt/acme.json:ro
      - /etc/localtime:/etc/localtime:ro
    mem_limit: 3.6G
    cpus: 1.9
    environment:
      - LOG_LEVEL=info
      - SUPERVISOR_LOGLEVEL=info
      - TZ=Europe/Amsterdam
      - POSTFIX_INET_PROTOCOLS=all
      - DOVECOT_INET_PROTOCOLS=all

      - ENABLE_SASLAUTHD=0

      # save all into single dir
      - ONE_DIR=1

      # security/filtering stuff
      # filter stuff
      - SPOOF_PROTECTION=1
      - ENABLE_CLAMAV=1
      - ENABLE_AMAVIS=1
      - ENABLE_POP3=0
      # show warnings from amavis filter
      - AMAVIS_LOGLEVEL=0
      # disable the dns blocklist for now
      - ENABLE_DNSBL=0
      # block attackers
      - ENABLE_FAIL2BAN=1
      - FAIL2BAN_BLOCKTYPE=drop
      # check valid connections with all tests
      - POSTSCREEN_ACTION=enforce
      # enalbe spam checker
      - ENABLE_SPAMASSASSIN=1
      - SPAMASSASSIN_SPAM_TO_INBOX=1
      - ENABLE_SPAMASSASSIN_KAM=1
      - "SA_SPAM_SUBJECT=[SPAM] "
      - ENABLE_MANAGESIEVE=1

      # we'll borrow traefik cretificates
      - SSL_TYPE=letsencrypt
      - SSL_DOMAIN=mail.XXX.cloud

      # limits
      # 50 mb
      - POSTFIX_MESSAGE_SIZE_LIMIT=52428800

    cap_add:
      - NET_ADMIN
      - SYS_PTRACE
    labels:
      - "traefik.enable=false"

Relevant log output

I’ve looked through the logs (docker-compose logs --follow) and noticed this coming up when I tried to send an email (both with thunderbird and with android gmail client).

mailserver_1                       | Feb 23 19:40:38 mail postfix/submission/smtpd[1455]: warning: hostname XXXXX.connected.by.freedominter.net does not resolve to address 2a10:3781:XXX::1: Name or service not known
mailserver_1                       | Feb 23 19:40:38 mail postfix/submission/smtpd[1455]: connect from unknown[2a10:3781:XXX:1]
mailserver_1                       | Feb 23 19:40:38 mail postfix/submission/smtpd[1455]: Anonymous TLS connection established from unknown[2a10:3781:XXX::1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
mailserver_1                       | Feb 23 19:40:38 mail postfix/submission/smtpd[1455]: warning: SASL: Connect to private/auth failed: Permission denied
mailserver_1                       | Feb 23 19:40:38 mail postfix/submission/smtpd[1455]: fatal: no SASL authentication mechanisms
mailserver_1                       | Feb 23 19:40:39 mail postfix/master[1399]: warning: process /usr/lib/postfix/sbin/smtpd pid 1455 exit status 1
mailserver_1                       | Feb 23 19:40:39 mail postfix/master[1399]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling

I’ve also tried it over ipv4, the same happens.

Other relevant information

No response

What level of experience do you have with Docker and mail servers?

I am inexperienced with docker
I am rather experienced with docker
I am inexperienced with mail servers
I am rather experienced with mail servers
I am uncomfortable with the CLI
I am rather comfortable with the CLI

Code of conduct

I have read this project’s Code of Conduct and I agree
I have read the README and the documentation and I searched the issue tracker but could not find a solution

Improvements to this form?

No response

About this issue

Original URL
State: closed
Created a year ago
Reactions: 1
Comments: 26 (16 by maintainers)

Most upvoted comments

I think in part it’s due to these two relative paths:

https://github.com/docker-mailserver/docker-mailserver/blob/ae05e6a7c379825fb464a648acc04b4074dd547f/target/postfix/master.cf#L22

and

https://github.com/docker-mailserver/docker-mailserver/blob/ae05e6a7c379825fb464a648acc04b4074dd547f/target/postfix/master.cf#L35

if I make those absolute as well, it indeed works (socket gets right permissions).

I just put this in my user-patches.sh as a test:

sed -i 's|/var/spool/postfix/private/auth|/var/tmp/sasl-auth|g' /etc/postfix/main.cf /etc/dovecot/conf.d/10-master.conf
sed -i 's|private/auth|/var/tmp/sasl-auth|g' /etc/postfix/master.cf

so maybe this should be a nice fix around that problem (not my user-patches, but the change of the configs)? to move that socket outside a docker mounted path?

If you want I could try and make a PR for it.

DavyLandman on Feb 25, 2023

Did I get this right: for now the bugfix is to change the container command to run something like

You could use our user-patches.sh script feature. That’ll run a script with the commands (minus the need to start supervisor at the end there), before services like Postfix are started.

All we’ve discussed is changing the path to be in a separate location which should avoid some potential issues. And the master.cf file from relative to absolute path.

However, if you’re not running :edge / v12, then the master.cf change might not work 🤷‍♂️ The linked Dovecot docs mention using a relative path for Postfix chroot (which is the case for all our current releases, except upcoming v12 that :edge provides), you can try it still and see if that works.

Other than that, the Dovecot config also configured this file to be user and group of docker (Dovecot uses this for /var/mail), instead of postfix. It may not work then if permissions are 660.

or is there any better quick fix until the PR is done and released in the container image?

You can technically extend the image with your own Dockerfile, and use COPY (or RUN sed if suitable) to apply such a patch via a custom image. Might be easier if you need to adjust the socket files ownership to be postfix instead of docker.

polarathene on Feb 25, 2023

I’m more than fine with placing it in /run/ as sasl-auth.sock; seems logical to me.

georglauterbach on Feb 25, 2023

@georglauterbach

I noticed that our Supervisor socket is located at /dev/shm/; do we want the new socket file to be there as well?

/dev/shm didn’t seem like a location I’d think storing unix socket files was relevant for. However, I have had a little look into it’s relevance with Docker and in particular supervisor to see why we’d have that in the first place…:

We use it in Docker apparently for ensuring a tmpfs mount, avoiding an issue with the default storage driver OverlayFS that didn’t play well with this type of file. Looking over the upstream issue, this was resolved with the 4.7 kernel release (July 2016). I’m skeptical that it’s still relevant if it was fixed with a newer kernel. I haven’t yet tried running the supervisor socket at it’s usual default in /var/run instead of /dev/shm yet though to confirm.

Perhaps it’s possibly related to the problem, and that plays into the different host / Docker environments for users that have always had this issue (pretty sure I’ve seen it in the past with Podman and macOS users specifically).

@alexanderadam you could try seeing if /dev/shm works better for you than /var/tmp?

polarathene on Feb 26, 2023

ATM there are no major changes to main.cf. If you want to give it a try, just go ahead, we’ll guide you 🙂

If you really can’t get to it, let me know. Then I will give it a try.

georglauterbach on Feb 26, 2023

However, if you’re not running :edge / v12, then the master.cf change might not work

@polarathene I ran my user-script thingy on 11.3.1 (in Docker). And it’s working again after that, the socket gets the right 0666 rights applied, and smtpd works again.

It seems you were right with that. I’m using unprivileged Podman with DMS 11.3.1 as this seems to be the latest stable version.

@alexanderadam can you run some of the commands I ran from within the container? Like, checking the rights of the file and using netcat to read from the socket as different users?

If you want I could try and make a PR for it.

Yes, please go ahead 😃

Also, I’m holding of on the PR, as I do not have a good way to test with regards to the bigger changes that have happened on main with preparation for v12.

DavyLandman on Feb 26, 2023

I actuall think /var/tmp/ is a good place 😃 Give it a concise name and all should be good.

georglauterbach on Feb 25, 2023

Hmm:

root@mail:/# ls -alh /var/spool/postfix/private/auth
srw-r-----+ 1 docker docker 0 Feb 23 19:53 /var/spool/postfix/private/auth

it’s s socket, but owned by docker user (uuid 5000) while the rest in that directory is owned by postfix (uid101).

I found some old issues on that file, and someone suggested removing it via user-patches.sh so I did that, but that didn’t seem to work (and the file is back with the same properties)

I also connected to it:

root@mail:/# nc -U /var/spool/postfix/private/auth
VERSION 1       2
MECH    PLAIN   plaintext
MECH    LOGIN   plaintext
SPID    1383
CUID    1
COOKIE  XXXXX
DONE

so the socket seems to work. however, if I try it as posfix:

root@mail:/# su -l -s /bin/bash postfix
postfix@mail:~$ nc -U /var/spool/postfix/private/auth
nc: unix connect failed: Permission denied
nc: /var/spool/postfix/private/auth: Permission denied

so could this be some kind of rights issue? what should I check?

DavyLandman on Feb 23, 2023