Thanks Noel for gently pointing out the obvious - there was in fact a non default timeout setting lurking set to 15 secs - the Cpanel exim setting is 20 secs.
Removed to let postfix timeout settings sit at default. All good. Appreciate it. > On 29 Mar 2019, at 8:21 am, Noel Jones <njo...@megan.vbhcs.org> wrote: > > On 3/28/2019 5:09 PM, Dale Harper wrote: >> Hi All, >> Cpanel environments have a artifical (“tar pitting”) delay in their smtp >> transaction when receiving email. >> Cpanel’s exim config has a “delay = 20secs”. (CPanel documentation: >> https://documentation.cpanel.net/display/78Docs/Exim+Configuration+Manager+-+Basic+Editor#ACLOptions >> Under - "Introduce a delay into the SMTP transaction for unknown hosts and >> messages detected as spam.”) >> I’m thinking that’s what is causing the following logged error sending from >> our postfix server to Cpanel email addresses. >> Final-Recipient: rfc822; em...@xyz.com >> Original-Recipient: rfc822;addr...@xyz.com >> Action: failed >> Status: 4.4.2 >> Diagnostic-Code: X-Postfix; conversation with xyz.com[x.x.x.x] >> timed out while receiving the initial server greeting >> Sits in deferred and eventually fails. >> This is now 2 different Cpanel hosting companies I’m seeing the same issue. >> The receiving exim server's artificial delay is 20sec, I know postfix’s >> various timeout defaults are well in excess of that (i.e. >> smtp_connect_timeout is default at 30secs). >> I’m taking responsibility and saying its my postfix server - as clearly most >> servers are handling the smtp transaction delay just fine - thought not all! >> - there is plenty of interwebs chatter out there about this exim delay = 20 >> causing timeouts. >> If you’ve seen and dealt with this I’d really appreciate your advice thank >> you. >> Dale > > > Have you adjusted the other smtp_*_timeout settings from their default values? > > In particular, this sounds as if you've reduced the smtp_helo_timeout to > something much less than the default 300s. > > If you need more help, please show "postconf -n" and log entries > demonstrating the problem. > > > -- Noel Jones
