The domain catchalls here aren't handled correctly, they are unconditionally added, even when the specific address is present. Eg. I have:

MariaDB [dbispconfig]> select source, destination, type from mail_forwarding;
+----------------------+-----------------------+----------+
| source               | destination           | type     |
+----------------------+-----------------------+----------+
| test_alias@dom.tld   | jesse@dom.tld         | alias    |
| test_forward@dom.tld | test_alias@dom.tld    | forward  |
| @dom.tld             | test_catchall@dom.tld | catchall |
+----------------------+-----------------------+----------+
3 rows in set (0.001 sec)

And a lookup for my alias should only return the single destination mail_user, but instead it returns the catchall address as well:

# postmap -q test_alias@dom.tld mysql:/etc/postfix/mysql-virtual_forwardings.cf                              
jesse@dom.tld,test_catchall@dom.tld

Postfix should already perform multiple queries with %s set in this order (access(5)): user@domain domain.tld .domain.tld user@

So checking the catchall can simply use WHERE s.source = '@%s', it will not match on the first query (user@domain), but will match on the second query (domain.tld).

Also I think the 3rd and the last select should both be for t.destination, not s.destination? I don't have an aliasdomain in my test setup yet, I'll try adding that and test things.

I reordered the selects from easiest (to understand) to hardest :)

See https://git.ispconfig.org/ispconfig/ispconfig3/-/blob/27e92946528d356c2bfab52daec313923cda2738/install/tpl/mysql-virtual_forwardings.cf.master

And note, the aliasdomain part is untested, I'll update if I find a problem.

So checking the catchall can simply use WHERE s.source = '@%s', it will not match on the first query (user@domain), but will match on the second query (domain.tld).

We cannot simply use %s as we intentionally disallow resolving with domain only by using the %d in the query. Regarding the manual using %d prevents postfix from querying with domain only.

I reordered the selects from easiest (to understand) to hardest :)

I ordered them by priority of targets (as I thought).

All results are returned (hence the catchall problem), so the order doesn't matter. If you do want to have a first-match-wins type setup, you could use multiple map files in virtual_alias_maps and "tables will be searched in the specified order until a match is found".

Not what I meant ;-) Was just the order that was logical to me. But I don't see why it should lead to the problem #2722 (comment 75727) mentioned. The simple query that was previously used also returns all matches from the forwarding table.

The simple query that was previously used also returns all matches from the forwarding table.

Indeed it could have, this test system isn't used for real email, I just happened to have a(n unused) catchall for some api testing. I setup an alias domain and will take a shot at getting things working for all of them.

Would you want this in a separate merge request? If you're in the mood for reviewing some related changes (ie. email forwarding), I'll make it part of MR #1009 (closed) and remove 'WIP'.

FWIW, this seems to be working correctly for everything I've tried: !1009 (6ff17b31)

Since virtual_alias_maps are recursive, and also handle the native aliasdomain format of @source.tld -> @dest.tld, the queries are quite simple (handle mail_forwarding for alias, forward and catchall in one lookup map, and aliasdomains in a subsequent map).

Just read through #2722 (closed), MR 1009 should fix it.