On Wed, May 22, 2024 at 05:35:25AM -0500, Greg Sims wrote:
> Thank you again for your feedback on this issue.
You're welcome, but I don't see anything in your reply that responds
directly to my requests for more detailed configuration and log data.
> I watched the workload in real time this morning and now have more
> insight into what is happening. It appears the large ISPs are using
> TLS connection as a way to throttle incoming traffic.
That conclusion seems hasty. The delays could be for any number of
reasons other than deliberate tarpitting, and it is not clear why such
tarpitting would be TLS-specific.
> I looked at the inbound mail queue and found most of the traffic going
> to gmail.com. I believe this is because of the 20 & 25 seconds delays
> google.com is injecting into the TLS connection.
To properly understand what is happening, you should first run "collate"
and see if that adds sufficient detail to pin down the delays, and if
not, then "smtp -v", and look for possible "RSET" timeouts. Perhaps
Gmail drops idle TLS connections faster than Postfix's 2s cache timeout?
Did you by any chance tweak the smtp/scache connection cache timeouts?
Longer timeouts risk the remote end closing the connection first, which
then causes problems trying to reuse it, ... and so raising the idle
timeouts can be rather counterproductive...
I'd be surprised if Google's front-end load-balancers drop TLS sessions
much faster than cleartext connections, ... but first you need to
determine what's happening during those 20s, for which more detailed
logging is needed, with "collate" being the simplest to try.
You may need to tweak the code slightly to match the date format used
by your log server.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
