[pfx] Is virtual_mailbox_maps redundant when virtual_alias_maps already checks mailbox existence

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]