Confused about alias_maps and virtual_alias_maps

Some background

Postfix inherited some features from older sendmail like milter and aliases. The file /etc/aliases is part of aliases inheritance and implemented by alias_maps. On the other side, postfix has virtual_maps/virtual_alias_maps for handle email aliasing. So what's the difference between them?

Parameter alias_maps

  • Used only for local(8) delivery

  • According to address class in postfix, email will delivery by local(8) if the recipient domain names are listed in the mydestination

  • The lookup input was only local parts from full email addres (e.g myuser from [email protected]). It discard domain parts of recipient.

  • The lookup result can contains one or more of the following:

    • email address: email will forwarded to email address
    • /file/name: email will be appended to /file/name
    • |command: mail piped to the command
    • :include:/file/name: include alias from /file/name

Parameter virtual_alias_maps

  • Used by virtual(5) delivery

  • Always invoked first time before any other address classes. It doesn't care whether the recipient domain was listed in mydestination, virtual_mailbox_domains or other places. It will override the address/alias defined in other places.

  • The lookup input has some format

    • user@domain: it will match user@domain literally

    • user: it will match user@site when site is equal to $myorigin, when site is listed in $mydestination, or when it is listed in $inet_interfaces or $proxy_interfaces. This functionality overlaps with functionality of the local aliases(5) database.

    • @domain: it will match any email intended for domain regardless of local parts

  • The lookup result must be

    • valid email address
    • user without domain. Postfix will append $myorigin if append_at_myorigin set yes

Why do we need /etc/aliases when having the email inside virtual aliases map seems to override it?

As you can see above, alias_maps(/etc/aliases) has some additional features (beside forwarding) like piping to command. In contrast with virtual_alias_maps that just forwards emails.

What is the purpose of having these 2 separate aliases mapping and when do we decide when to use what?

The alias_maps drawback is that you cannot differentiate if the original recipient has [email protected] or [email protected]. Both will be mapped to root entry in alias_maps. In other words, you can define different forwarding address with virtual_alias_maps.

Why did fail2ban (which is configured to email to root@localhost) first follow email address given in alias_maps (/etc/aliases/) and later decides to ignore that once virtual_alias_maps was added?

Before virtual_alias_maps added: root@localhost was aliased by alias_maps because localhost was listed in mydestination.

After virtual_alias_maps defined: The entry root (in virtual_alias_maps) doesn't have domain parts and localhost was listed in mydestination, so it will match root [email protected].

Why doesn't all services read email aliases mentioned in /etc/aliases and they only work when the email aliases are added in virtual alias map?

Command mail root will send email to root. Because lacks of domain parts, postfix trivial-rewrite will append myorigin to domain parts. So, mail will be send to root@myorigin.

Before virtual_alias_maps added: Unfortunately, myorigin isn't listed in mydestination, so it won't be processed by alias_maps.

After virtual_alias_maps added: The entry root (in virtual_alias_maps) doesn't have domain parts and myorigin (obviously) same as myorigin, so it will match root [email protected].


  1. /etc/aliases is there primarily for local delivery, for example, mail to root from cron, etc, it's nice to keep your local aliases separate, virtual_alias_maps can also be used with SQL DBs, and so on.

  2. virtual_alias_maps is for when you have virtual users (and virtual domains), often that do not map to system users, but if you don't have virtual domains, and very few users, that sort of functionality may not be necessary.

  3. fail2ban doesn't care, it just submits email to the MTA.

  4. You need to be more specific, which services, how and where do they submit mail?