Skip to content

Draft: Use pgsql tables in Postfix configuration

Postfix can use SQL database queries to identify and route list traffic. This MR enables such usage.

It provides:

  • a pgsql table type in mta/postfix.py
  • disabling creation of the postfix_lmtp table
  • a sample, fully-commented config/postfix-pgsql.cf to reference in Postfix's main.cf for transport_maps and local_recipient_maps
  • documentation of the feature in config/postfix.cfg and docs/mta.rst.

The original rationale for the patch was that for very large sites creation of the postfix_lmtp file takes perceptible linear time, resulting in a quadratic time for full migration of the list configurations. Implementation of the patch resulted in a 200:1 speedup for the first 10,000 lists of a 20,000 list site. Implementation also provides

  • a single source of truth for identifying mailing list mailboxes, and
  • a zero-downtime online approach to Mailman 2-to-3 list migration (just put Postgres ahead of the Mailman 2 transport in transport_maps, of course this doesn't deal with archives, but they can run in parallel with a bit of trickery).

Remaining issues:

  • Postfix documentation recommends not using the database to replace postfix_domains, but experience suggests that even with PostgreSQL served by a separate host, 2 or 3 queries per incoming message do not materially slow message flow.
  • I'm thinking that the Postfix configuration file is probably better placed in /etc/postfix. The rationale for putting the postfix_* files in $var_dir/data was at least partly that Mailman likely would not be able to write to /etc/postfix, but that's not a problem now. Then having, eg, transport_maps = pgsql:mailman-lists.cf is more readable.

Merge request reports