How to get sieve subaddress filtering to work?

[daks]

Hi,
I'm running DMS 15.1 and would like to use Sieve subaddress filtering. I read the doc and also this discussion but still can't get it to work.

• I have enabled recipient delimiter on both Postfix and Dovecot

$ cat config/postfix-main.cf 
recipient_delimiter = +
$ cat config/dovecot.cf 
recipient_delimiter = +

• I have restarted/recreated the container
• I have checked that recipient_delimiter is enabled inside the container, on both Postfix and Dovecot, at runtime (using postconf -C all and doveconf commands)
• I have, outside of the container, edited mail-data/<domain>/<user>/home/.dovecot.sieve to add something like what is is the doc or something even simplier. I am sure that the dovecot file path is correct because I can execute other instructions from it, or, if I insert errors, I see them in the .dovecot.sieve.log log file

I looked at sieve doc elsewhere and the DMS sieve example looks fine.

Also I tried to debug sieve filtering using vnd.dovecot.debug but that doesn't work.

Any idea of what can be wrong?

EDIT
This is the filter I use

if envelope :detail "to" "test" {
    fileinto "INBOX.test";
    stop;
}

and I test it sending a mail to [email protected]

[polarathene]

This is an easy mistake when getting started with Sieve. You need to make sure you have the correct Sieve extensions loaded.

In your case that would look like this:

require ["envelope", "subaddress", "fileinto"];

Perhaps the docs were not clear with those examples, but they were meant to be snippets to swap from the previous full sieve script example which does start with a require line.

---

Reference

Just for anyone else landing here, I've provided a full example that you can run locally, just copy/paste this compose.yaml and run the commands below to try 👍

name: example

services:
  dms:
    image: ghcr.io/docker-mailserver/docker-mailserver:${DMS_RELEASE:-15.1.0}
    hostname: mail.example.test
    # These ENV below are just to simplify the reproduction and aren't relevant to the sieve functionality itself:
    environment:
      ENABLE_AMAVIS: 0
      ENABLE_UPDATE_CHECK: 0
    # Normally this would be `volumes` for you, but `configs` is useful for examples,
    # as it allows embedding the files into a single `compose.yaml` example that you can copy/paste to run locally:
    configs:
      - source: dms-accounts
        target: /tmp/docker-mailserver/postfix-accounts.cf
      # Sieve script is associated to a specific account/mailbox:
      - source: dms-sieve
        target: /tmp/docker-mailserver/[email protected]
    # This is a workaround for running this `compose.yaml` example locally without proper DNS setup.
    # It's only needed for the `swaks` command to successfully deliver mail on port 25:
    networks:
      default:
        aliases:
          - example.test

# The Docker Compose `configs` feature inlines file content into `compose.yaml` (convenient for reproductions)
# NOTE: `$` will be inferred as an ENV on the host to replace with a value if found,
#       `$$` is required as an escape to opt-out of that feature when an actual `$` is expected in the file content.
configs:
  # Created via `setup email add [email protected] secret`:
  # - Username: `[email protected]`
  # - Password: `secret`
  dms-accounts:
    content: |
      [email protected]|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.

  dms-sieve:
    content: |
      require ["envelope", "subaddress", "fileinto"];

      # Is the envelope subaddress (`envelope :detail`) of the recipient ("to") exactly `test`? (case-insensitive):
      if envelope :detail "to" "test" {
        # Store the mail into your `test` mailbox (it will be created if it does not exist yet).
        # The mail will exist at: /var/mail/example.test/john.doe/.INBOX.test/new
        fileinto "INBOX.test";
      }

$ docker compose up -d --force-recreate

# Send a test mail to the mail address with the subaddress `test`:
$ docker compose exec dms swaks --silent --server localhost --from [email protected] --to [email protected]

# Check that it was delivered into the expected `test` inbox folder:
$ docker compose exec dms ls /var/mail/example.test/john.doe/.INBOX.test/new
'1758764721.M6145P775.mail.example.test,S=893,W=914'

Troubleshooting

In this case your sieve extension probably failed to compiled. If it was successful you'd find it will have a .svbin like this:

$ docker compose exec dms ls -a /var/mail/example.test/john.doe/home

.  ..  .dovecot.sieve  .dovecot.svbin

When compilation fails, the .svbin will be missing and when a mail arrives Dovecot will add a log file about what went wrong (NOTE: :detail isn't logged below as an error because it's on the same line as envelope which came first):

$ docker compose exec dms cat /var/mail/example.test/john.doe/home/.dovecot.sieve.log

sieve: info: started log at 2025-09-25 01:57:14 +0000.
.dovecot: line 4: error: unknown test 'envelope' (only reported once at first occurrence).
.dovecot: line 7: error: unknown command 'fileinto' (only reported once at first occurrence).
.dovecot: error: validation failed.

Those two have extensions of the equivalent name, while :detail would rely upon the subaddress extension to be required.

[polarathene]

UPDATE: See alternative answer if you're not wanting to take the Postfix pcre approach.

---

In my debugging I only changed the sieve rules. I don't see the need to recreate the container for that. Even when I activated dovecot debug/trace, I did it directly in the container (using supervisor to restart dovecot process).

I understand that recreating the container is the "standard" process when providing help for DMS, but in this particular case I knew what I was doing and, but tell me if I'm wrong, it wasn't needed.

The suggestion was because it tends to be more reliable, and even when a user believes that they're confident in what they're doing (not you specifically, just a common experience), they're sometimes not aware of some parts of DMS involved.

In this case I don't see any support in check-for-changes.sh, so updating the sieve config from the DMS config volume would not trigger any update there as no copy of these sieve rules to the actual mailboxes, that only happens during container creation. Similarly, even if you change the sieve rule at the location Dovecot actually reads from, assuming compilation is successful there should be a .svbin variant that Dovecot would prefer IIRC, so the user must also remember to update that too.

Restarting a service in the container via supervisorctl can work, as can dovecot reload, but this doesn't tell Dovecot to do things like re-compile sieve rules. Depending on the system, automating the compilation via script can have a race condition too, something I've encountered before and required a workaround in our DMS scripts.

So by all means feel free to take a more manual approach and tinker without the annoyance of recreating the container, but should you experience observations like you described with making a change fixing the sieve rule, and then reverting it and still having the fix working, non-deterministic behaviour like that is the kind of thing that shouldn't really be happening and recreating the container should provide a more deterministic reproduction for consistent behaviour. So doing the latter can be a helpful troubleshooting step (while also the former potentially throwing you off as you experiment).

I opened an issue recently related to our CLI support with Rspamd DKIM key generation and a race condition with check-for-changes.sh conflicting with that which gave unreliable behaviour depending on timing of the setup command and our change detection poll rate.

In this case, just updating the .sieve rules file at the mailbox directly does seem to work without even needing to run dovecot reload or compiling .svbin (gets done implicitly). So that .svbin caveat I mentioned I think was DMS compiling that in advance and in some scenarios the timestamp was older than the .sieve source which made Dovecot unhappy at some point 😓

---

I think I already knew how postfix lookup tables. But it doesn't directly explain how my user+wtf@ becomes user@ which makes dovecot unaware of the detail part.

I thought I explained it fairly clearly 😅

Postfix will iterate through one or more tables trying the original address first (such as [email protected]), that is also the only input the pcre table would receive. If no match, then other tables like texthash continue to get queried with progressively less specific inputs, the first being to drop any subaddress, hence [email protected] would be checked, and eventually no local-part of the address at all, just @example.com.

Just a quick update because I still need to do more tests to confirm. It looks like the following is enough to make the catch-all address work

I disabled the pcre table, and modified the postfix-virtual.cf to match your suggestion:

dms-aliases:
  content: |
    @example.test catchall
    [email protected] [email protected]
    [email protected] [email protected]

I had to adjust the 2nd line, since the DMS FQDN / hostname is mail.example.test, while mailbox domain is example.test, when the alias doesn't provide a domain-part to resolve, Postfix will append it's myorigin setting IIRC, and that would be associated to mydestinations by default in DMS since that setting includes the configured hostname.

$ postconf -x myorigin
myorigin = mail.example.test

When that happens a separate alias table is also checked (postfix-aliases.cf => /etc/aliases, different syntax with only local-part to match) which are not virtual aliases. Those can resolve to another address or alias to resolve, or a valid system account (/etc/passwd with users like root, amavis, etc) for internal delivery (Dovecot doesn't manage storage for that, but they'll end up stored in files at /var/mail via Postfix directly).

If I did not do that modification, then mail would be rejected since no catchall user could be found. You could also omit the domain-part on the left-side to just catchall, then regardless of domain-part, any local-part that's catchall would match.

Anyway... your idea did not work with the stripped down reproduction compose.yaml I provided. So if you found it to be working for you, that seems odd? You may have configured DMS to ignore it's assigned FQDN from mydestination to share it with the same mailbox domain for your accounts, but I don't think that'd change the behaviour I've observed 🤔

---

I imagine that adding the PCRE one will, but I don't like this solution, it seems way too complicated for me.

The PCRE solution will work, simply because we have the original input address and can match on it exactly as we wanted to, and ensure that a wildcard match still captures and preserves the subaddress.

I wouldn't say it's too complicated. You have the one catch-all regex pattern, and then for any address you want to opt-out of going through that catch-all address, similar to how you already have it you add an earlier match to redirect elsewhere (potentially the same as the input).

Doing that properly just requires:

• /^ + $/ to signal the start and end of the expression, as you don't want to match a substring ([email protected] would match [email protected] for example, which is bad)
• Escaping the . so it's not matching "any character" but explicitly a ..
• (\+.+)? is an optional match group, that matches the subaddress (eg: +hello+world). This is where some extra care was needed to ensure it started from the first + and captured the remainder even with an extra + in the value (our account docs do document this subaddressing matching expectation). For that pattern to work as expected, we needed to add the U (ungreedy) flag after the pattern.
• The catch-all only differs by having .* (anything) for it's local-part, aside from the optional subaddress.

So that's all handled for you, with that reference explanation you shouldn't need to think much about it beyond copy/paste the pattern and adjust the local-part of the address to what you want (escaping any .).

If you do not plan to frequently update this config, it's effectively set and forget going forward.

---

You can also use a tool like the regex101 website which can let you experiment and visualize the pattern (I've added the gm flags here so you can test multiple lines of inputs at once)

It also provides a side-panel with a breakdown of the pattern logic and match results:

If you want to play with that, here's the pattern plus test values you can copy/paste:

/^.*(\+.+)?@example\.test$/Ugm

[email protected]
[email protected]
[email protected]

---

I hope to be able to find some time to understand how it can be solved in a simpler way.

pcre isn't the only way, other tables that let you customize the match logic better would also work. I saw one for SQL, but then you need to configure a DB and DMS has no conveniences in place for switching to that.

I am a little curious of why you'd want a catch-all?

• It would seem better to only accept mail for explicit mailbox addresses/aliases you want to receive mail at, throwing an error to the sender if they use an invalid address.
• I assume it's preferred as a convenience to bulk alias addresses you want to accept to forward to a single mailbox account?

[daks]

Restarting a service in the container via supervisorctl can work, as can dovecot reload, but this doesn't tell Dovecot to do things like re-compile sieve rules.

It looks like sieve rules are recompiled at runtime. I imagine that when an email arrives, it verifies the sieve rules and compiles if source is newer than compiled file.

I think I already knew how postfix lookup tables. But it doesn't directly explain how my user+wtf@ becomes user@ which makes dovecot unaware of the detail part.

I thought I explained it fairly clearly 😅

I was talking about my specific case without pcre. Reading the doc, I don't understand how my user+wtf@ is treated differently from test+wtf@. This may come from another internal part.

For the rest... I appreciate that you take so much time to answer, providing a lot of details about how thinks works, and solutions but... there is so much text that I found myself lost in your explanations :) So I admit I have not read it all.

Two things:

• when I talked about the PCRE solution being too complicated, I was thinking about XKCD 1171 https://xkcd.com/1171/ :) bacause I thought that it would need one regex for each catch all address
• I can confirm that the solution I indicated works for me as needed. I will detail it in another comment

[polarathene]

Reading the doc, I don't understand how my user+wtf@ is treated differently from test+wtf@. This may come from another internal part.

I thought I had explained that?

• 1. [email protected] (match? no)
  2. [email protected] (match? yes, propagates +wtf) => Resolved to [email protected]
• 1. [email protected] (match? no)
  2. [email protected] (match? no)
  3. user+wtf (match? no)
  4. user (match? no)
  5. @example.test (match? yes, no propagation) => Resolved to [email protected]

If you are comfortable, you can glance over the related upstream source code here, where you can see the final @domain check seems to be missing some logic with ext related vars, and I believe here is the related lookup logic calling that method which has commentary with a higher-level view that specifically calls out a matched domain like @example.test key in the table will strip away the subaddress (aka "address extension").

So if you want that fixed, or to know why the extension is not propagated, you'll need to engage with upstream Postfix project about it (which I think relies on mailing lists rather than modern platform like Github).

---

For the rest... I appreciate that you take so much time to answer, providing a lot of details about how thinks works, and solutions but... there is so much text that I found myself lost in your explanations :) So I admit I have not read it all.

I understand. I am verbose for the benefit of anyone else that lands here and would benefit from the knowledge (there isn't that much info out there on the topic from the looks of it).

when I talked about the PCRE solution being too complicated, I was thinking about XKCD 1171 https://xkcd.com/1171/ :) bacause I thought that it would need one regex for each catch all address

You would only have a regex equivalent of each entry in your standard postfix-virtual.cf, you would just use postfix-regexp.cf instead. Very little difference, just ugly to look at with regex syntax.

I can confirm that the solution I indicated works for me as needed. I will detail it in another comment

I think you have a misunderstanding of why you think that works. I will respond on your related comment.

[daks]

  5. `@example.test` (_match? yes, no propagation_) => Resolved to `[email protected]`

"no propagation" -> that's is what I was talking about. The part I don't understand, and I think you didn't explain it. Why is there no propagation of the tag? You seems to think it may be a bug upstream.

For the rest, I clearly understood (and already knew) how it works.

[polarathene]

Short answer:

• I explained it pretty clearly with citations to upstream docs/source?
• As to why catch-all doesn't propagate, you'd need to ask upstream why they chose not to support that (not necessarily a bug).
• Use either workaround solution I provided if you want to preserve the subaddress with a catch-all. Your own answer does not support that (despite seeking how to solve that problem).

---

The part I don't understand, and I think you didn't explain it.

I did explain it, but as you mentioned you did not read everything I wrote to you:

---

Why is there no propagation of the tag?

As stated:

• [email protected] can be an entry in postfix-virtual.cf, which would match but not propagate the subaddress to whatever you resolve.
• [email protected] would be the next attempt to query in postfix-virtual.cf:
  • If the original input had a subaddress (prior query), then this will propagate it to the address the alias resolves to.
  • NOTE: This happens after the previous query to each table configured for virtual_alias_maps, thus if using pcre table with postfix-regexp.cf, you may not reach this point if a regex match was already found.
• user+tag followed by user are checked next if there is still no match, same as the previous two steps, but no @example.com / domain-part in the table entry.
• @example.com is the last query to try find a match for.

If you consider without subaddress, it's quite simple matching logic right? [email protected] would match user 👍

That same logic is the same for [email protected] matching user+tag, regardless of Postfix thinking about subaddress, it would not propagate in this case (I'm sure there are scenarios where you would not want it to, or you resolve to an address with your own preferred subaddress instead)

This might be where your confusion happens. When Postfix is aware of the subaddress due to the recipient_delimiter setting identifying the split of the local-part of the address, two additional queries without the subaddress are performed, and those will propagate the extension unless you disable that globally.

Now when you think about the catch-all domain query, it would always match with the subaddress present, so attempting a match afterwards without a subaddress would not be reached. Postfix chose to keep the behaviour like matching specific subaddress, discarding it from propagation, rather than always propagating. Without a setting to adjust that, only one audience is happy 😅 (personally I think it makes more sense to propagate here too, but that may be a breaking change to introduce for those relying on it to strip the subaddress, which may have been the case before subaddress support landed, I don't know)

Basically, subaddress support just became two extra queries that extract the subaddress, and propagate it.

---

You seems to think it may be a bug upstream.

As my previous comment notes with links to upstream source code, the behaviour is as I've explained it and implemented in that Postfix code. Nothing to do with DMS.

We can only workaround that with pcre, or preserving the original address with the X-Original-To header (which Dovecot can then read and treat as the envelope recipient address, or Sieve could match on with an adjusted conditional rule).

I don't know if it's a bug per se, as I am not familiar with the decisions of upstream. There is not much context in the source I linked which only shows commits of released tags. Maybe if you find the actual source instead of a mirror you'd get a more granular scope of commits and can find some more insights 🤷‍♂️

You can try and get in contact with the Postfix devs, and if they agree to make it possible to propagate with the catch-all, then you can use that in DMS once it becomes available in Debian (but that'd likely be 1-2 years time).

[polarathene]

I've identified another way that will work, but I don't know if it's ideal.

This was through references:

• https://github.com/orgs/docker-mailserver/discussions/3898#discussioncomment-8526599
• https://github.com/orgs/docker-mailserver/discussions/3898#discussioncomment-10263045
• [TODO]: Sieve - Access original recipient address before alias resolution #3904 (comment)

---

Instead of using the pcre table to fix the issue on Postfix side, I've had Postfix preserve the original recipient address via the X-Original-To header, and configured Dovecot to trust that as the ORCPT value it sources when no Delivered-To header is present.

name: example

services:
  dms:
    image: ghcr.io/docker-mailserver/docker-mailserver:${DMS_RELEASE:-15.1.0}
    hostname: mail.example.test
    # These ENV below are just to simplify the reproduction and aren't relevant to the sieve functionality itself:
    environment:
      ENABLE_AMAVIS: 0
      ENABLE_UPDATE_CHECK: 0
    # Normally this would be `volumes` for you, but `configs` is useful for examples,
    # as it allows embedding the files into a single `compose.yaml` example that you can copy/paste to run locally:
    configs:
      - source: dms-accounts
        target: /tmp/docker-mailserver/postfix-accounts.cf
      - source: dms-aliases
        target: /tmp/docker-mailserver/postfix-virtual.cf
      # Sieve script is associated to a specific account/mailbox:
      - source: dms-sieve
        target: /tmp/docker-mailserver/[email protected]
      - source: dms-sieve
        target: /tmp/docker-mailserver/[email protected]
      - source: user-patches
        target: /tmp/docker-mailserver/user-patches.sh
      - source: dovecot-extra
        target: /tmp/docker-mailserver/dovecot.cf
    # This is a workaround for running this `compose.yaml` example locally without proper DNS setup.
    # It's only needed for the `swaks` command to successfully deliver mail on port 25:
    networks:
      default:
        aliases:
          - example.test

# The Docker Compose `configs` feature inlines file content into `compose.yaml` (convenient for reproductions)
# NOTE: `$` will be inferred as an ENV on the host to replace with a value if found,
#       `$$` is required as an escape to opt-out of that feature when an actual `$` is expected in the file content.
configs:
  # Created via `setup email add [email protected] secret`:
  # - Username: `[email protected]`
  # - Password: `secret`
  dms-accounts:
    content: |
      [email protected]|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.
      [email protected]|{SHA512-CRYPT}$$6$$sbgFRCmQ.KWS5ryb$$EsWrlYosiadgdUOxCBHY0DQ3qFbeudDhNMqHs6jZt.8gmxUwiLVy738knqkHD4zj4amkb296HFqQ3yDq4UXt8.

  dms-aliases:
    content: |
      [email protected] [email protected]
      [email protected] [email protected]
      @example.test [email protected]

  dms-sieve:
    content: |
      require ["envelope", "subaddress", "fileinto"];

      # Is the envelope subaddress (`envelope :detail`) of the recipient ("to") exactly `ext-tag`? (case-insensitive):
      if envelope :detail "to" "ext-tag" {
        # Store the mail into your `ext-tag` mailbox (it will be created if it does not exist yet).
        # The mail will exist at: /var/mail/example.test/john.doe/.INBOX.ext-tag/new
        fileinto "INBOX.ext-tag";
      }

  # Configure Postfix to append the `X-Original-To` header:
  # See "Command Attribute Syntax" section: https://www.postfix.org/smtp.8.html
  user-patches:
    content: |
      postconf lmtp_destination_recipient_limit=1
      postconf -F 'lmtp/unix/command=lmtp flags=O'

  # Have Dovecot set the ORCPT from this header, when the RCPT value is not present:
  # https://doc.dovecot.org/2.3/configuration_manual/protocols/lmtp_server/#envelope-addresses
  # https://doc.dovecot.org/2.3/settings/core/#core_setting-lda_original_recipient_header
  dovecot-extra:
    content: |
      lda_original_recipient_header = X-Original-To

With that compose.yaml run the following:

docker compose up -d --force-recreate

# Send to catch-all alias that will resolve to store at `[email protected]` mailbox:
docker compose exec dms swaks --silent --server localhost --from [email protected] --to [email protected]

# Send to an alias that will resolve to store at the `[email protected]` mailbox:
docker compose exec dms swaks --silent --server localhost --from [email protected] --to [email protected]

There is a slight difference in these mails, the subaddress is still missing for the wildcard Delivered-To (default envelope recipient address) when sent to [email protected].

$ docker compose exec dms bash -c 'cat /var/mail/example.test/john.doe/.INBOX.ext-tag/new/*'

Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mail.example.test
        by mail.example.test with LMTP
        id NRsxHTqM3GjdAwAAUi6ngw
        (envelope-from <[email protected]>)
        for <[email protected]>; Wed, 01 Oct 2025 02:04:42 +0000
X-Original-To: [email protected]
X-Comment: SPF check N/A for local connections - client-ip=::1; helo=mail.example.test; [email protected]; receiver=example.test
Received: from mail.example.test (localhost [IPv6:::1])
        by mail.example.test (Postfix) with ESMTP id 59CCA240591
        for <[email protected]>; Wed,  1 Oct 2025 02:04:42 +0000 (UTC)
Date: Wed, 01 Oct 2025 02:04:36 +0000
To: [email protected]
From: [email protected]
Subject: test Wed, 01 Oct 2025 02:04:36 +0000
Message-Id: <[email protected]>
X-Mailer: swaks v20240103.0 jetmore.org/john/code/swaks/

This is a test mailing

$ docker compose exec dms bash -c 'cat /var/mail/example.test/jane.doe/.INBOX.ext-tag/new/*'

Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from mail.example.test
        by mail.example.test with LMTP
        id IM/xMk2M3GjdAwAAUi6ngw
        (envelope-from <[email protected]>)
        for <[email protected]>; Wed, 01 Oct 2025 02:05:01 +0000
X-Original-To: [email protected]
X-Comment: SPF check N/A for local connections - client-ip=::1; helo=mail.example.test; [email protected]; receiver=example.test
Received: from mail.example.test (localhost [IPv6:::1])
        by mail.example.test (Postfix) with ESMTP id A8FA2240591
        for <[email protected]>; Wed,  1 Oct 2025 02:05:01 +0000 (UTC)
Date: Wed, 01 Oct 2025 02:05:01 +0000
To: [email protected]
From: [email protected]
Subject: test Wed, 01 Oct 2025 02:05:01 +0000
Message-Id: <[email protected]>
X-Mailer: swaks v20240103.0 jetmore.org/john/code/swaks/

This is a test mailing

When Sieve is running, the envelope address appears to be sourced lda_original_recipient_header (unset by default).

I did also come across a similar/related setting lmtp_hdr_delivery_address (alternative mentions RCPT TO ORCPT, albeit a slight typo there) but this did not seem to affect anything with alternative (default is final), while none would remove the Received for line and Delivered-To headers Dovecot appends.

---

NOTE: As per one of the DMS references cited, you could avoid setting lda_original_recipient_header (which may have some security concerns), and match by address instead of envelope, and the X-Original-To header instead of To (Delivered-To? / ORCPT?).

require ["envelope", "subaddress", "fileinto"];

#if envelope :detail "to" "ext-tag" {
if address :detail "X-Original-To" "ext-tag" {
  fileinto "INBOX.ext-tag";
}

[daks]

This is the (mostly) working solution I found.
The idea is having a user account which works as normal but also as a catch-all for the domain. There is also a test account.

Using

# postfix-virtual.cf
@domain.tld catchall
catchall [email protected]
[email protected] [email protected]
[email protected] [email protected]

(no problem for me with the second line you mention)

and a sieve rule similar to the one in the docs :

• mail sent to user+tag@ ends in user's INBOX.tag mailbox
• mail sent to test+tag@ ends in test's INBOX.tag mailbox
• mail sent to whatever@ ends in user's INBOX mailbox
  but
• mail sent to whatever+tag@ is also stored in user's INBOX. Which seems coherent with the problem I had before.
  It means that if you needs sieve rules for a non-existent mailbox (like contact@) you need to explicit declare it as an alias with [email protected] [email protected]

I can provide more details about my configuration to understand why yours doesn't work, but mine is pretty standard... nothing fancy in compose.yaml (except ports are on 80xx and I use nft rules to redirect trafic), config only contains accounts and virtual aliases and recipient_delimiter.

[polarathene]

I can provide more details about my configuration to understand why yours doesn't work, but mine is pretty standard...

I have a full compose.yaml example, you can try it with your suggested answer and should see that it does not work. Very simple to do.

• mail sent to whatever+tag@ is also stored in user's INBOX. Which seems coherent with the problem I had before.

Correct, because you didn't fix anything?

• mail sent to user+tag@ ends in user's INBOX.tag mailbox

Correct, because you now have an entry equivalent to the one you had for test, that will be selected first if you mail to [email protected] directly, no need for the catchall/@domain.tld entries before it, those two entries have lower priority to match.

• It means that if you needs sieve rules for a non-existent mailbox (like contact@) you need to explicit declare it as an alias with [email protected] [email protected]

Right, you add another explicit entry, no wildcard catchall is used.

(no problem for me with the second line you mention)

You either didn't test with an address that would only match the catchall @domain.tld (eg: [email protected]) or you have also set hostname: domain.tld instead of hostname: mail.domain.tld (aka "bare domain" as per our FAQ guidance).

With either of those being true, you'd not have hit the same failure.

---

When I said it was not a valid solution, I shared my postfix-virtual.cf:

@example.test catchall
[email protected] [email protected]
[email protected] [email protected]

If you send mail to [email protected] directly, or [email protected], then yes it works and goes into the expected mailbox and the sieve rule stores it in INBOX.tag.

Anything that actually uses the wild-card match though strips away the subaddress, and then only has catchall to query as an alias again (resolving to [email protected]) but no subaddress is propagated (as explained here).

---

So while you have marked your config as the answer you're happy with, it's a misunderstanding of the intended functionality for a catchall to preserve the subaddress.

Correct solutions are:

• PCRE table (postfix-regexp.cf instead of postfix-virtual.cf): https://github.com/orgs/docker-mailserver/discussions/4574#discussioncomment-14532392
• Postfix + Dovecot X-Original-To header (ORCPT): https://github.com/orgs/docker-mailserver/discussions/4574#discussioncomment-14558355

Both with verified reproduction compose.yaml.