On Tue, Jun 14, 2022 at 04:57:49PM +0200, Yves-Marie Le Pors Chauvel wrote:
> ==========================================================================
> #service type private unpriv chroot wakeup maxproc command + args
> # (yes) (yes) (yes) (never) (100)#
> ==========================================================================
> transport unix - - y - 3 smtp
Is it really called "transport"??? Give it a better name...
> # Transport policy
> transport_initial_destination_concurrency = 1
> transport_destination_concurrency_limit = 3
> transport_destination_rate_delay = 0
> transport_destination_recipient_limit = 2
Replace "transport_" with "somename_" for whatever "better" name you
chose.
The low recipient count increases demand for concurrent connections,
raise this to whatever limit the service provider allows.
> smtp_connection_cache_on_demand = yes
> smtp_connection_cache_time_limit = 2s
> smtp_connection_reuse_time_limit = 300s
These are IIRC default settings, no need to set these explicitly.
> I am receiving a lot of deferred messages from this Mailbox Provider : *Too
> many connections from your IP*...
>
> This kind of deferred message is happening when postfix is closing a
> connection and reopening a new one. It seems that my delay to close the
> connection and open a new one is much more shorter than the Mailbox
> Provider to see that the connection has been closed, so he sees 4
> connections and starts deferring messages.
>
> Is there a way to implement a delay between connection closing and
> reopening for a specific transport in Postfix, while still using
> connection reuse ?
The whole point of connection reuse is to avoid connection setup
latency. If you want delays, simpler to first just turn off reuse
for this "transport" (pick a better name):
transport unix - - y - 3 smtp
-o { smtp_connection_cache_on_demand = no }
And with a process limit of 3, you hardly need a concurrency limit...
--
Viktor.
