Yes, both lines have. These are in the default config. The '-m ${extension}' parameter is just responsible for the delivery within user's mailbox to the corresponding folder. But its seems, that the catchall resolution takes effect first.

No, it doesn't help. This postmap output is NULL with '%s' and ''%u@%d' too. The situation is the same with a domain, that doesn't have catchall setting.

Maybe this log can be interesting:

postfix/qmgr[5929]: 824D81C70B: from=<validmailbox@domain.com>, size=1413, nrcpt=1 (queue active)
amavis[1206]: (01206-01) Passed CLEAN {RelayedInternal}, MYNETS/MYUSERS LOCAL [192.168.122.1]:46326 [192.168.122.1] <validmailbox@domain.com> -> <validmailbox+ext@domain.com>, Queue-ID: 1DFE61C705, mail_id: QOqwdCjP8JFt, Hits: -0.86, size: 405, queued_as: 824D81C70B, dkim_new=dkim:domain.com, 332 ms
postfix/smtp[6130]: 1DFE61C705: to=<validmailbox+ext@domain.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1.7, delays=1.3/0.02/0.01/0.4, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 824D81C70B)
postfix/qmgr[5929]: 1DFE61C705: removed
postfix/pipe[6138]: 824D81C70B: to=<catchall@domain.com>, relay=dovecot, delay=0.38, delays=0.06/0.01/0/0.3, dsn=2.0.0, status=sent (delivered via dovecot service)
postfix/qmgr[5929]: 824D81C70B: removed

In the end, the dovecot delivery gets the catchall address, but the validmailbox+ext would be the proper address.

Thank you, it works! The validmailbox+ext@domain.com style addressed email arrive into the validmailbox, not the catchall mailbox.

But the dovecot LDA/LMTP gets the goto address from the alias table, so the destination mailbox delivery (dovecot -m parameter) or the lmtp_save_to_detail_mailbox feature does not work. Even if the domain don't have a catchall address.

According to Postfix document, virtual(5):

ADDRESS EXTENSION
       When a mail address localpart contains the optional recipient delimiter
       (e.g., user+foo@domain), the  lookup  order  becomes:  user+foo@domain,
       user@domain, user+foo, user, and @domain.

       The   propagate_unmatched_extensions   parameter  controls  whether  an
       unmatched address extension (+foo) is propagated to the result of table
       lookup.

So Postfix will query 'user+foo@domain' first. If you have catch-all account, it will return catchall address directly without trying 'user@domain'. Still no idea how to force Postfix to query 'user@domain' instead.

Still no idea which files we should update to fix this issue. Sorry.
I will do some more testing to try it again, and don't wait for me, do some testing yourself too.

Postfix:

- http://www.postfix.org/postconf.5.html# … alias_maps
- http://www.postfix.org/virtual.5.html

Dovecot: http://wiki2.dovecot.org/Variables

Yes, I found a possible solution, but it is not perfect. In main.cf I have deleted the "proxy:mysql:/etc/postfix/mysql/catchall_maps.cf" and "proxy:mysql:/etc/postfix/mysql/domain_alias_catchall_maps.cf" from virtual_alias_maps parameters, so this looks like now:

virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf, proxy:mysql:/etc/postfix/mysql/domain_alias_maps.cf

And in the mysql vmail.alias table I modified the catchall record like this: address: @domain.com, goto: catchall@domain.com. Note to @ sign in front of the address filed. This two modifications solved my original problem. But it is not compatible with iredadmin. And if you have alias domains, on those catchall feature doesn't work, but for me it isn't problem.

For SQL backends, it should be possible if we modify SQL query to skip '+extension' part in email address (username+extension@domain.com), but for LDAP, looks like mission impossible.

What about those with LDAP?

Thanks

I've had a look at this myself today.

As was said above, the problem on LDAP is that:

1. The "+" cannot be stripped from LDAP lookups easily, so the catchall eventually succeeds.
2. Postfix will try user+extension@domain on the lookups first, then user@domain after that, but before the catchall for user+extension@domain succeeds, it never tries the second pass.

Possible solutions include stripping out extensions before doing the lookup - but that's probably going to obfuscate delivery, as the headers might get rewritten to hide the extension. Alternatively, if one could change the virtual_alias_maps list between iterations of lookup, that'd solve it (first pass without catchall, second pass including catchall). However, I don't think that's possible either.

Actually, a final option would be not to include a catchall lookup at all. Postfix, will hit the alias_maps in the following order normally:

user@domain, user, @domain

and with extension:

user+ext@domain, user@domain, user+ext, user, @domain

So surely if the LDAP entries for catchalls had similar service enablement and object classes to aliases, the normal postfix lookup process would work for plus addressing and for catchall?

The key differences I spot are, for catchall:

query_filter    = (&(objectClass=mailUser)(accountStatus=active)(|(mail=@%d)(shadowAddress=@%d)))
result_attribute= mailForwardingAddress

and for alias:

query_filter    = (&(|(mail=%s)(shadowAddress=%s))(accountStatus=active)(enabledService=mail)(enabledService=deliver)(|(objectClass=mailAlias)(&(objectClass=mailUser)(enabledService=forward))))
result_attribute= mailForwardingAddress

So some careful re-wording of that alias filter might be required. Or maybe there's a different map lookup that I'm missing, that would be a better candidate?

I haven't had any chance to test this myself yet, and would need to spin up a development VM in which to do it. It'll probably be a few days before I can do that.