Explain why we use static transport maps and custom subdomains.

1 files changed, 16 insertions, 0 deletions

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 %}