On Wed, Jun 08, 2022 at 06:58:40PM +0300, Nikolaos Milas wrote:
> We are not using any milters except the one you mentioned, for DKIM signing.
The milter may be performing DKIM signature checks on inbound mail,
signing would be only for outbound. DKIM signature checks may involve
DNS lookups, which could introduce some latency if the remote zone is
uncooperative.
> For your reference, I am attaching (zipped) the whole message from
> wetransfer for which I earlier posted the delivery log (with mail local
> parts changed consistently, and with wetransfer true download links
> scrambled consistently).
You won't find anyone on this list to whom you can outsource the
detailed analysis of the problem. You'll have to do that on your end,
by tracing the dataflow through your server, and determine the source
of the problem. 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...).
> You can study the mail content at your convenience.
Nobody else is going to do that.
> If not, why this phenomenon does not occur with other messages?
That's for you to find out.
> 0.0.0.0/0 postfwdcheck
> [::]/0 postfwdcheck
Make sure this has reasonable latency.
> So, for messages from mailgw1.noa.gr we apply:
>
> [2001:648:2ffc:1115::27] gwcheck
> 83.212.5.27 gwcheck
>
> which is:
>
> gwcheck = reject_unverified_recipient, reject_unauth_destination
Make sure this has reasonable latency.
--
Viktor.
