https://bugs.exim.org/show_bug.cgi?id=1788
Bug ID: 1788
Summary: Deliveries to one ISP sometimes fail silently after
T=remote_smtp defer on first delivery attempt
Product: Exim
Version: 4.84
Hardware: x86-64
OS: Linux
Status: NEW
Severity: bug
Priority: medium
Component: Delivery in general
Assignee: nigel@???
Reporter: exim@???
CC: exim-dev@???
I've been running exim mailservers on Debian for years. Having upgraded the
server to Debian Jessie in December 2015, we've noticed some emails going
missing. We're running the "4.84-8+deb8u2" of the exim4-daemon-heavy package.
Doing an "exim4 --version" reports:
Exim version 4.84 #2 built 15-Dec-2015 04:15:40
Copyright (c) University of Cambridge, 1995 - 2014
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2014
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS
move_frozen_messages Content_Scanning DKIM Old_Demime PRDR OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
What's wierd is that it only appears to be happening to emails destined for the
ISP "PlusNet" (although it happens to their email addresses under multiple
domains). Most of the time, emails are delivered without problem.
When the fault occurs, no delivery retry is made and no NDR is generated.
Searching for the problem, I've found very little. I did try clearing out the
retry queue by stopping Exim, deleting the "retry, retry.lockfile,
wait-remote-smtp, and wait-remote-smtp.lockfile" files in /var/spool/exim4/db,
and restaring Exim. This was to ensure that there was no queue corruption.
This appears to have not worked.
A cut-down and log entry is below (with email addresses and domains changed):
2016-02-01 20:58:01 1aQLXt-0006xu-N5 SA: Debug: SAEximRunCond expand returned:
'true'
2016-02-01 20:58:01 1aQLXt-0006xu-N5 SA: Debug: check succeeded, running spamc
2016-02-01 20:58:01 1aQLXt-0006xu-N5 SA: Action: scanned but message isn't
spam: score=-5.0 required=5.0 (scanned in 0/0 secs | Message-Id:
CAK5bOtF6P==FbW9S6zYOgz_BM1Zj9vcSfuYbbKg5bgwyHxJaPw@???). From
<mailinglist-bounces@???> (host=localhost [127.0.0.1]) for
first1.last1@???, first2.last2@???,
first3.last3@???
2016-02-01 20:58:01 1aQLXt-0006xu-N5 <= mailinglist-bounces@???
H=localhost (bear.myhostdomain.net) [127.0.0.1] P=esmtp S=6886
id=CAK5bOtF6P==FbW9S6zYOgz_BM1Zj9vcSfuYbbKg5bgwyHxJaPw@???
2016-02-01 20:58:02 1aQLXt-0006xu-N5 => /home/localuser/Maildir/
(localuser@???) <localuser@???> R=userforward
T=address_directory
2016-02-01 20:58:02 1aQLXt-0006xu-N5 == user@???
<first2.last2@???> R=dnslookup T=remote_smtp defer (-53): retry time
not reached for any host
2016-02-01 20:58:03 1aQLXt-0006xu-N5 => gmailuser@???
<first3.last3@???> R=dnslookup T=remote_smtp
H=gmail-smtp-in.l.google.com [2a00:1450:400c:c07::1b]
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 DN="C=US,ST=California,L=Mountain
View,O=Google Inc,CN=mx.google.com" C="250 2.0.0 OK 1454360283
l195si17273277wmg.115 - gsmtp"
2016-02-01 21:09:25 1aQLXt-0006xu-N5 Completed
I've checked the logs and the queue was run at 20:52:48 and 21:22:48, so the
queue running had nothing to do with this "disappearing delivery".
An example when an email is successfully delivered to this email address is:
2016-02-06 20:29:32 1aS9Ty-00010B-6p => user@???
<first2.last2@???> R=dnslookup T=remote_smtp H=mx.avasin.plus.net
[212.159.9.200] C="250 F8VT1s0010Nc4R9018VV8l mail accepted for delivery"
We've seen the problem occur on the following domains, which are all PlusNet
domains:
- waitrose.com
- userdomain.idps.co.uk
- (and another user's .org.uk domain hosted by PlusNet)
Exim is doing all the translations between aliases and the real addresses
before delivery.
I'm not sure where to look next to debug this occasional issue further - can
anyone advise please?
--
You are receiving this mail because:
You are on the CC list for the bug.
