From ee046343f3bbb43dc48a8ad72b5cb16dc0a24ee6 Mon Sep 17 00:00:00 2001 From: Guilhem Moulin Date: Thu, 10 Jul 2014 00:53:15 +0200 Subject: Explain why we use static transport maps and custom subdomains. --- roles/IMAP/files/etc/postfix/transport | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'roles/IMAP/files/etc') 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 -- cgit v1.2.3