Much appreciated, Stephen and Torge! Really!

Yours,

Allan Hansen hansen@rc.org

On Mar 27, 2020, at 0:47 , Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

hansen@rc.org writes:

...

The link gives just this:

421 - [too many sessions from <source IP>] The sending IP address has exceeded the five maximum concurrent connection limit. Configure your sending server to establish no more than five concurrent connections.

1. Is that a legitimate excuse to refuse passing on emails or is cox.net too stingy?

Very stingy (Postfix default is 50) but possibly legit. From http://www.postfix.org/postconf.5.html (edited for brevity):

smtpd_client_connection_count_limit (default: 50)

   WARNING: The purpose of this feature is to limit abuse. It
   must not be used to regulate legitimate mail traffic.

Note the warning. Cox may have had trouble with their MXes getting DoS'ed, either intentionally or by poorly configured remote MTAs.

Modern MTAs all can do connection caching, which means they can stream multiple messages over one connection. Permitting many simultaneous connections might be (a) a courtesy to legacy and unconfigured modern systems that don't cache, or (b) an optimization that might be appropriate among a collection of mutually trusting MTAs in a cloud "mail cannon" service.

...

2. Is that a setting we need to change in Mailman somewhere? Or should this be handled in some Postfix setting?

I see Torge already suggested smtp_destination_concurrency_limit, thanks Torge! That is the obvious setting, but there are some other possibilities which I'll mention here, as the Postfix default is 20, so this may affect other mail traffic adversely.

I think you should prefer MTA setting. IIRC, Mailman 3 doesn't have any self-throttling capability anymore, but relies on the MTA to tell it when to stop. Even if it does, it is very likely to be more efficient all around to have the MTA do the throttling. What should happen (unless you're a very high-volume server talking to an MTA you own) is that Mailman jams as many messages as possible into the MTA's queue, and the MTA takes care of throttling. This is more efficient, because the MTA can do a (very :-) limited amount of negotiation with its remote peer, which Mailman cannot do.

Check the configuration of the following options in your Postfix configuration (documentation at postconf.5.html URL above):

smtp_connection_cache_destinations (default: empty) smtp_connection_cache_on_demand (default: yes) Note: this default presumably means that, unless somebody told it NOT to, your Postfix "should" try to cache the connection when Mailman sends a ton to cox.net. If it's yes, try putting cox.net in smtp_connection_cache_destinations (see documentation for correct syntax). smtp_connection_cache_time_limit (default: 2s) smtp_connection_reuse_count_limit (default: 0) smtp_destination_concurrency_limit (default: $default_destination_concurrency_limit) smtp_destination_recipient_limit (default: $default_destination_recipient_limit)

Hope this helps, and feel free to ask more questions. Note I probably can't help more with Postfix (my host is Exim), but Mark and I believe Abhilash are quite familiar with production Postfix installations. I can't promise their availability; the Postfix channels may be more prompt and helpful.