On 8/6/2022 5:44 μ.μ., Wietse Venema wrote:
Possible causes (there may be more):
- There is a problem with the network connection between mailgw1
and mailgw1 that causes some connections to have excessive retries.
This could be a data-dependent problem. About 20 years ago, someone
fixed a Postfix networking problem by replacing bad network hardware
(a different port on a switch).
- There is a problem in the file system that causes delays in the
fsync() system call. Postfix will not reply that the mesasage has
been "received" before that system call completes successfully. If
you are using a networked file system, see my previous point. fsync()
performance also depends on how a disk drive manages its cache.
- vmail2 is using header_checks, body_checks, or smtpd_milters that
take an insane amount of time. These are by their nature data-dependent.
Sorry, no time to examine up your Postfix configuration.
Thank you Wietse for this analysis.
My big question is why this happens *ONLY* to particular messages, esp.
those originating from wetransfer.com and sharepointonline.com, and it
happens *consistently* to those.
If there was a system / OS issue, it would occur randomly on various
messages (from various sender domains). But in fact the phenomenon is
very selective and directly associated with particular sender domains.
For example, two more such sender domains (where delays also occur, and
do so consistently) are apmascongress.org and uea.ac.uk.
These messages (with delays) are a *very* small percentage of the total
mail we receive.
Moreover, we don't do any header / body etc checks. All such checks
have been performed during amavis examination at mailgw1. We only
deliver mail to the final recipient.
As I wrote to Victor, the only milter is the DKIM signing one, used for
outgoing messages.
How could we further investigate the issue, e.g. by more thoroughly
(i.e. in high detail) logging postifx activity on mails from those domains?
If needed, I can provide more extended logs for your analysis.
Please advise! I am out of ideas.
Thanks again,
Nick
