Paul Tomblin via Mailman-users writes:
Not sure exactly what you want; check the doc Mark recommends for
I'm trying to set the destination_concurrency_limit, but only for one outgoing domain (rochester.rr.com) which complains of too many incoming connections
rr.com? My condolences.
this list is run for little old ladies who barely understand that their computer has to be on in order to receive email, we tend to manage the subscriptions and re-subscriptions manually rather than ask the end users to do it.
Unless you have legal reasons to personalize or there's a bunch of sophisticated users on the same list who want it, one obvious candidate solution is to switch off personalization so that Mailman can batch outgoing mail to a given domain (Postfix will give all the recipient addresss to rr.com's MTA, but send the body content only once). Of course if rr.com rate limits by address, that's not going to work,
In mailman 2, I had my mailing list aliases in the virtual_alias_maps, and now in mailman 3 it's in transport-maps, and it's meant that some of the configuration I had before doesn't work.
For routing TO Mailman, transport_maps takes precedence over virtual_alias_maps, and that can require modifying your Postfix configuration. But mail going out FROM Mailman 3 works exactly as it did in Mailman 2 (modulo any bugs fixed in Python 3 or Mailman :-), so if you have a backup of your old configuration that will work. If you used transport_maps for this purpose, you just insert the path to the old table before Mailman's postfix_lmtp table.[1]
"transport_maps" is plural because you can put any number of tables in there. I forget the way precedence is determined within a table, but Postfix checks for a match in each table in list order, and as soon as it finds a match in a table, it sets the transport for that address and message to the transport found, and ignores the rest of the tables. I would expect your (incoming) Mailman table and (outgoing) finicky recipient table are disjoint, so order won't matter.
Steve
Footnotes: [1] Strictly speaking, you could be doing something weird with some of your Mailman 2 lists, but it seems to me to be extremely unlikely that any of them were mentioned in your old transport_maps.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan