[exim-dev] [Bug 2535] Server reply is truncated in later bou…

Inizio della pagina
Delete this message
Reply to this message
Autore: admin
Data:  
To: exim-dev
Vecchi argomenti: [exim-dev] [Bug 2535] New: Server reply is truncated in later bounce messages but in first is ok
Oggetto: [exim-dev] [Bug 2535] Server reply is truncated in later bounce messages but in first is ok
https://bugs.exim.org/show_bug.cgi?id=2535

--- Comment #1 from Jeremy Harris <jgh146exb@???> ---
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 == user@???
(user@???, user@???) <user@???> 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:<user@???>: 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 == user@??? 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 myuser@???

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.