Hi,
I want to verify my understanding of the virtual_alias_maps →
virtual_mailbox_maps fallback chain before making a configuration
change, and also explore whether the chain can be simplified further.
---
Setup:
virtual_alias_maps = tcp:127.0.0.1:9926,
proxy:mysql:/etc/postfix/mysql-vam.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-vmm.cf
smtpd_reject_unlisted_recipient = yes (default)
Port 9926 is an in-house TCP lookup daemon. For each RCPT TO it runs
two lookups against our database:
Step 1 — checks whether the mailbox exists for the recipient address,
with domain-alias resolution (if the recipient domain is a configured
alias, it resolves to the canonical domain before checking). Returns the
address if found. For external domains, returns immediately without
proceeding to step 2.
Step 2 — checks for explicit aliases and catchalls for the recipient
address.
If both steps return nothing, port 9926 returns NOT_FOUND. Postfix
then tries the MySQL fallback (mysql-vam.cf), which checks the same
alias table as step 2. If that also returns nothing,
smtpd_reject_unlisted_recipient triggers virtual_mailbox_maps.
The virtual_mailbox_maps MySQL lookup is a direct mailbox existence
check — same table and same status conditions as step 1 above.
---
Question 1 — Is virtual_mailbox_maps redundant here?
Since step 1 already checks mailbox existence with identical
conditions, by the time virtual_mailbox_maps is reached the same
question has already been answered "no" by the same table with the same
filters. If the user existed and matched those conditions, step 1 would
have returned the address, satisfied virtual_alias_maps, and
virtual_mailbox_maps would never have been reached.
We are therefore considering replacing the MySQL virtual_mailbox_maps
with a TCP lookup on a separate port that immediately returns NOT_FOUND
without hitting the database, on the basis that this check is always a
no-op at that point.
Is our understanding correct? Are there any Postfix-level scenarios —
such as lookup caching, address normalisation, or anything in how
smtpd_reject_unlisted_recipient interacts with these maps — where
virtual_mailbox_maps could legitimately find a recipient that
virtual_alias_maps step 1 already missed?
---
Question 2 — Can virtual_mailbox_maps be skipped entirely?
Taking this further: is there a way to configure Postfix so that
NOT_FOUND from virtual_alias_maps is treated as a rejection directly,
without consulting virtual_mailbox_maps at all?
For example, does setting virtual_mailbox_maps = (empty) while
keeping smtpd_reject_unlisted_recipient = yes achieve this? Or does
Postfix require a non-empty virtual_mailbox_maps to be able to reject
unlisted recipients for virtual mailbox domains?
Thanks
Rajesh Mishra
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
