diff options
| -rw-r--r-- | roles/IMAP/files/etc/postfix/transport | 16 | ||||
| -rw-r--r-- | roles/MX/templates/etc/postfix/main.cf.j2 | 3 | ||||
| -rw-r--r-- | roles/MX/templates/etc/postfix/virtual/transport.j2 | 16 |
3 files changed, 34 insertions, 1 deletions
diff --git a/roles/IMAP/files/etc/postfix/transport b/roles/IMAP/files/etc/postfix/transport index d40ac5d..94210e0 100644 --- a/roles/IMAP/files/etc/postfix/transport +++ b/roles/IMAP/files/etc/postfix/transport @@ -1 +1,17 @@ +# Each valid address user@example.org is aliased (on the MX) into some +# example.org/user@xxx.fripost.org, and non-defaults next-hop:port are +# chosen here in that table, depending on 'xxx'. The reason for such +# indirection is that there is only one qmgr(8) daemon, which delegate +# the routing strategy to the trivial-rewrite(8), which in turns queries +# transport_maps. Hence high latency maps such as LDAP or SQL would +# congestion the queue manager. On the other hand, virtual aliasing is +# performed by cleanup(8), multiples instances of which can run in +# parallel. See http://www.postfix.org/ADDRESS_REWRITING_README.html . +# +# /!\ WARNING: xxx.fripost.org should NOT be in the list of valid +# domains ($virtual_alias_domains)! Otherwise at the next iteration of +# the alias resolution loop the domain will be validated but not the +# address, and the MTA will reply with "Recipient address rejected: User +# unknown in virtual alias table". + filter.mda.fripost.org amavisfeed:[127.0.0.1]:10041 diff --git a/roles/MX/templates/etc/postfix/main.cf.j2 b/roles/MX/templates/etc/postfix/main.cf.j2 index e3b8ce0..22b68f3 100644 --- a/roles/MX/templates/etc/postfix/main.cf.j2 +++ b/roles/MX/templates/etc/postfix/main.cf.j2 @@ -55,7 +55,8 @@ relay_domains = # bottlenecks on trivial_rewrite(8) due to slow LDAP lookups in # tranport_maps. virtual_transport = error:5.1.1 Virtual transport unavailable -virtual_alias_domains = ldap:$config_directory/virtual/domains.cf +virtual_alias_domains = !cdb:$config_directory/virtual/transport + ldap:$config_directory/virtual/domains.cf virtual_alias_maps = pcre:$config_directory/virtual/reserved_alias.pcre # first we do the alias resolution... ldap:$config_directory/virtual/alias.cf diff --git a/roles/MX/templates/etc/postfix/virtual/transport.j2 b/roles/MX/templates/etc/postfix/virtual/transport.j2 index 9eac2be..57a0349 100644 --- a/roles/MX/templates/etc/postfix/virtual/transport.j2 +++ b/roles/MX/templates/etc/postfix/virtual/transport.j2 @@ -1,3 +1,19 @@ +# Each valid address user@example.org is aliased (on the MX) into some +# example.org/user@xxx.fripost.org, and non-defaults next-hop:port are +# chosen here in that table, depending on 'xxx'. The reason for such +# indirection is that there is only one qmgr(8) daemon, which delegate +# the routing strategy to the trivial-rewrite(8), which in turns queries +# transport_maps. Hence high latency maps such as LDAP or SQL would +# congestion the queue manager. On the other hand, virtual aliasing is +# performed by cleanup(8), multiples instances of which can run in +# parallel. See http://www.postfix.org/ADDRESS_REWRITING_README.html . +# +# /!\ WARNING: xxx.fripost.org should NOT be in the list of valid +# domains ($virtual_alias_domains)! Otherwise at the next iteration of +# the alias resolution loop the domain will be validated but not the +# address, and the MTA will reply with "Recipient address rejected: User +# unknown in virtual alias table". + reserved.fripost.org reserved-alias: {% if 'LDA' in group_names %} |