>smtp_connection_cache_destinations enables connection caching
>*unconditionally* for the named destinations. This means it keeps
>a connection open for several seconds even when the destination has
>no email in the active queue.
>
>I think that you can stick with the default settings, which
>keep connections open only when they can be reused immediately.
Matus UHLAR - fantomas:
this unfortunately did not work without listing destinations explicitly in
smtp_connection_cache_destinations so I had big backlog of messages for
those domains, even if I set smtp_connection_cache_time_limit=30 and
enabled smtp_tls_connection_reuse...
On 06.04.22 10:43, Viktor Dukhovni wrote:
What is your smtp_destination_concurrency_limit? Do you have working
inbound recipient validation? If you're relaying mail for many
subdomains, perhaps not, and the output congestion is a result of
delays in returning bounces to non-responsive or slow destinations.
On 06.04.22 10:00, Wietse Venema wrote:
I suspect that you have a different problem: using the same Postfix
delivery agents (default_transport = smtp) for forwarding internal
domains, and for external deliveries.
this is not an internal domain not out client, these are three subdomains of
remote domain/organization (different IPs from different IP range) I have no
relationship with.
I have created special transport for them:
slowsmtp unix - - y - - smtp
-o syslog_name=postfix/slow
-o smtp_connection_cache_time_limit=30
and set transport_maps accoringly:
.example.com slowsmtp:
and settings to avoid any concurrency:
slowsmtp_destination_concurrency_limit=1
smtp_tls_connection_reuse=yes
smtp_connection_cache_destinations=a.example.com, b.example.com, c.example.com
it was listing those three subdomains that helped - solution didn't work
without this.
those mailservers allow no concurrency and I was unable to open second smtp
connection for minutes after closing first one.
I can only guess shitty router/firewall or insanely aggressive fail2ban
settings.
forcing reuse of SMTP connection was the only way I managed to flush queue
of more than a hundred messages waiting days for delivery.
so far I haven't noticed similar problem with anyone (luckily)
to repeat - I was only curious if I can avoid listing those subdomains in
hall_of_shame (smtp_connection_cache_destinations)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I feel like I'm diagonally parked in a parallel universe.