On Wed, Jun 08, 2022 at 04:55:50PM -0400, Viktor Dukhovni wrote:
> In particular, was the delay during network transmission, or in
> content processing after "."? Perhaps you can log a "WARN" or "INFO"
> action in "end_of_data" restrictiosn, and see when that happens
> (before milters run, don't recall whether inflow_delay happens
> first...).
I checked, and in_flow_delay happens before cleanup(8) begins handling a
new message, so isn't the problem here, since the message envelope and
headers (at least Message-Id) are handled promptly, so the latency is
either in the network transmission of the mesage body, the end_of_data
checks or the milter.
You'll have to figure out which. You might make progress by segregating
the problem messages to arrive on a dedicated port, with a dedicated
smtpd+cleanup configuration, and enabling verbosity ("-v" in master.cf)
in cleanup, though a simpler first step would be a "WARN" or "INFO"
action in an end_of_data restriction, and noting the time delay from
message start for that to happen. Milter processing of the message
body will (I believe) happen after end_of_data restrictions.
--
Viktor.
