Description

Bit of a history with this one:

• Considering our project is docker focused, this is a horrible choice for grep to track down 🤣
• Presently, this represents our default 5000:5000 static vmail user and group and the relevance AFAIK is only for Dovecot. Possibly only when regarding /var/mail ownership.
• This topic relates to addressing support for non-static UID+GID ownership in /var/mail which is mostly a subset of our LDAP users. Ideally we can drop the chown -R logic (or shift it into a setup ... command as a troubleshooting tool we can document scenarios for).

The issue description is documenting any concerns / knowledge regarding this docker account, so that a future PR can justify renaming it to something more appropriate such as vmail / dms-vmail.

• May be a good idea to try tackle this first: [TODO]: Tests should share a more thorough helper method for mail delivery checks #3554
• 5000:5000 is our default, but with v13 this becomes configurable via ENV.

Before Dovecot - Creation of docker user + group (Dockerfile)

The docker user and group created during the Dockerfile build were added via this Sep 2015 commit from the original DMS project author. The only context provided was a reference to this issue, but it's lacking information on why the account was added.

Back then I think the mail account support was quite a different story, and it's likely become irrelevant for the original purpose?

EDIT: When DMS switched from Courier to Dovecot in DMS v2 (2016), it was configured with LDA instead of LMTP, with Postfix master.cf running the process as the docker user.

Dovecot configs referencing docker user + group

April 2016 - DMS migrated from Courier + Cyrus to Dovecot, which introduced various configs referencing the docker user and group:

• Dovecot UserDB auth socket
  • This doesn't seem relevant anymore in DMS, it was originally for supporting Dovecot LDA.. but we later changed to Dovecot LMTP in Oct 2016.
  • There is also one for the master process (not to be confused with master accounts userdb feature). Dovecot docs on service auth { ... } provides a bit of insight. This was also part of the original Dovecot config support, and presumably not serving a purpose anymore either. I've not seen this service auth { ... } configuration for auth-userdb / auth-master mentioned in common setup guides (Dovecot docs, and a few others that only touch on the Postfix SASL socket).
  • Example of configuring Postfix to send mail to Dovecot LDA, which has a auth-userdb config with the vmail user and group.
• Dovecot mail_privileged_group
  • Also from the 2016 PR. This has a reference in the Dovecot docs - Quick Config under the Mbox section, where it references /var/mail location to allow Dovecot to create locks.
  • Dovecot Docs - Settings also covers it with the same reasoning. It's used as a fallback. Technically if we did set it to mail which I believe is the default for /var/mail (at least with the Debian base image), we may not need to bother with chown -R at all 🤔
  • privileged_group is a similar setting for service configs, but advises to use mail_privileged_group.
  • Dovecot UserDB config adds uid + gid overrides to enforce the static docker user and group (LDAP can override this via ENV + attributes from filter query).

Dovecot vmail user / group and common 5000 ID

Dovecot Docs - Service Config notes various processes that have a default of user=root, with advice that you could set an explicit non-privileged user instead when all mail accounts would belong to a single UID. Otherwise the processes only temporarily run as root and drop to the UID returned from the UserDB lookup result.

I haven't looked into the reasoning for 5000 as the UID/GID choice, there didn't appear to be any discussion about it in DMS. It does seem to be common advice found online though (EDIT: Seems that it might have originated from this Dovecot doc (which presently notes it's outdated and from 2010):

• https://wiki.archlinux.org/title/Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube#User
• https://serverfault.com/questions/348589/dovecot-2-auth-userdb-permissions
• https://superuser.com/questions/737198/what-permissions-on-var-mail-directory
• [BUG] Restarting the container changes the owner of folders in /var/mail to 5000 #2238 (comment)

/var/mail ownership and sticky-bit

Presently at startup and when check-for-changes.sh service is running, chown -R is applied to /var/mail for the 5000:5000 ownership.

There wasn't much context about how this arrived in the project as a fix/workaround (a follow-up limited the scan depth to avoid applying further if permissions looked correct for the scanned directory).

• A recent PR that will allow making the vmail ID 5000 configurable revealed the common failures, which came down to /var/mail ownership not aligning with the Dovecot user / group preventing it from creating files to store mail.
• It's probably fine to follow earlier advice above from Dovecot docs and keep and leverage the default mail group? IIRC this location was configured with a sticky-bit, like this discusses.
  • NOTE: Earlier PR discussion regarding sticky-bit I have various comments there, one documenting a gotcha with losing sticky-bit from some operations depending on kernel support.
  • Setting vmail as user and group is probably fine, but may not need to be done beyond /var/mail (while we do have our own default layout with /var/mail/{fqdn}/{account}/, it is possible to configure that to be one level less).

supervisord Web UI

Unrelated to the above, there is another config that has a similar user (docker-mailserver) + password for the supervisord web UI when enabled: #1758

• Improve logging significantly – color is back! #1758 (comment)
• Improve logging significantly – color is back! #1758 (comment)

May 2025

Identified an issue with fetchmail when configured with --mda option to deliver to Dovecot. The fetchmail process needs to match the UID/GID of user to deliver to in the Dovecot UserDB, or it needs to run as root for setuid/setgid to work.