How to setup subaddresses with sieve and a custom recipient_delimiter?

[pn2new]

I am migrating my DMS setup to a new server. Sending and receiving mails works, but somehow the use of subaddresses fails, and I don't understand why. Basically, when I send a mail to user-folder@mail.com, or to user+folder@mail.com, I would like the folder folder to be created and the incoming mail to be moved there. This worked in my previous setup.

What I have done is set up these config files:

XXX/config# cat postfix-main.cf
recipient_delimiter = +-

XXX/config# cat dovecot.cf
recipient_delimiter = +-

XXX/config# cat user\@mail.com.dovecot.sieve
require [ "variables", "envelope", "fileinto", "subaddress" ];

if envelope :is :user "to" "user" {
  if envelope :matches :detail "to" "*" {
    set :lower "name" "${1}";
  }

  if string :is "${name}" "" {
    fileinto "INBOX";
  } else {
    fileinto "${name}";
  }
}

This seems not to be sufficient, and the subaddress part is not recognized and split off. In the logs I get:

mail dovecot: auth: passwd-file(user-folder@mail.com): unknown user
mail postfix/smtpd[659]: NOQUEUE: reject: RCPT from XXXX 550 5.1.1 <user-folder@mail.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<XXXX> to=<user-folder@mail.com> proto=ESMTP helo=<XXXX>

Basically, no user with name user-folder is found, which of course is not the idea...

What is missing here?

(my real email address of course is not mail.com, I have edited files and logs to protect my privacy)

UPDATE 1

I now also placed a .dovecot.sieve file with the same content as above into /maildata/mail.com/user and compiled it with sievec, and now subaddressing works with the + separator. However, it does not work with the - separator. Running doveconf and postconf inside the running contained seems to indicate that the config files listed above are not "mixed" into the configuration of these programs. Why is this not the case?

UPDATE 2

I see, I basically needed to --force-recreate the container, otherwise the config changes were not considered. Now everything works.

I wonder which of the above steps were unnecessary, though, since I do not remember doing these all in my previous setup.

[polarathene]

I see, I basically needed to --force-recreate the container, otherwise the config changes were not considered. Now everything works.

... I do not remember doing these all in my previous setup.

Since DMS v14 we only run the bulk of our container setup scripts when the container is first created. This change was done because those scripts were fragile across container restarts as they often made assumptions of no existing modifications, as if they always ran for the first time (no existing configs copied into the container service files, etc) which was prone to various bugs. In DMS v15 we completed that transition for how container startup is handled and this reduced the rate of bug reports related to that buggy behaviour of previous releases of DMS.

Thus to ensure configuration is properly applied, we typically advise you to destroy any existing DMS container and create a fresh one with docker compose up --force-recreate. Any data that should persist would be in your volumes, while anything else in the container filesystem layer will be discarded (it is commonly assumed that restarting a container with docker compose restart would have done this and only persisted data via volumes, but that is not the case).

Normally you don't have to worry about this sort of concern with containers, but because DMS bundles multiple services into one container and is effectively integration glue of third-party software, we are more susceptible to the problem.

---

I wonder which of the above steps were unnecessary

You should only need the configuration files like our docs cover (I rewrote our docs for sub-addressing in the past year IIRC, they were not very good prior), and then to ensure you start a fresh DMS container with --force-create 👍

The intent is that once up and running, you shouldn't need to update config very often going forward. DMS does have support for some config files and TLS certs to be monitored and when changes are detected we handle those. That doesn't cover sieve scripts at present, but might in future.

[polarathene]

If it interests you here are the relevant DMS docs for sub-addressing support:

• https://docker-mailserver.github.io/docker-mailserver/v15.0/config/advanced/mail-sieve/#subaddress-mailbox-routing
• https://docker-mailserver.github.io/docker-mailserver/v15.0/config/account-management/overview/#sub-addressing