https://bugs.exim.org/show_bug.cgi?id=2535
--- Comment #1 from Jeremy Harris <[email protected]> --- The second bounce "Delay reason" you show came out of the retry database rather than directly from a response from a delivery attempt. This is inferred from the timestamps in the logs: 2020-02-28 11:21:44.020 [26154] 1j7aNs-00053R-NC == [email protected] ([email protected], [email protected]) <[email protected]> R=dnslookup T=remote_smtp defer (-44) H=alt4.gmail-smtp-in.l.google.com [2607:f8b0:4001:c15::1b]:25: SMTP error from remote mail server after RCPT TO:<[email protected]>: 452-4.2.2 The email account that you tried to reach is over quota. Please direct\n452-4.2.2 the recipient to\n452 4.2.2 https://support.google.com/mail/?p=OverQuotaTemp v19si1583625jan.34 - gsmtp 2020-02-28 11:51:30.811 [27238] 1j7aNs-00053R-NC == [email protected] routing defer (-51): retry time not reached 2020-02-28 11:51:30.824 [27239] cwd=/var/spool/exim 7 args: /usr/local/sbin/exim -t -oem -oi -f <> -E1j7aNs-00053R-NC 2020-02-28 11:51:30.836 [27239] 1j7eB0-00075L-Qn <= <> R=1j7aNs-00053R-NC U=mailnull P=local S=2611 M8S=0 RT=0.002s T="Warning: message 1j7aNs-00053R-NC delayed 4 hours" from <> for [email protected] The most-recent delivery attempt was at 11:21 but this warning-message is being produced at 11:51 - the queue-runner has been called but (as logged) the retry time for the message is not yet expired hence no delivery attempt. But the warning message time has, so we're generating a bounce. The message stored in the retry DB is truncated, to 150 chars length. The code comment says that DBM records have a size limit, so that is (or at least was at some time) the reason. Your case has run into this and is losing useful info partly because of the lengths of both the server name and ipv6 address (plus the verbosity of Exim's annotation of the circumstances of the SMTP error). We certainly should try to support such lengths of address and name better, for the ipv6 world of today. I don't find a mention of a fix record size in the Sleepycat documentation on the web for BDB - but the situation is somewhat confused by the Oracle ownership. This does tie in, somewhat, with the longterm wish to get away from BDB. Whatever we manage to do I'm afraid it won't be quick. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
