Your message dated Tue, 13 Sep 2016 23:39:37 +0000
with message-id <[email protected]>
and subject line Re: When a relay host lacks an IPv6 interface, mail
heisenbounces
has caused the Debian Bug report #837535,
regarding When a relay host lacks an IPv6 interface, mail heisenbounces
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
837535: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837535
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: exim4-config
Version: 4.84.2-1
I doubt that this bug, which affects only some users, will be
your most urgent bug to fix. However, the fix is subtle.
Since I can now describe the fix (though I have not attached a
patch), I report the fix here. The fix can be implemented and
packaged whenever you have time, whether before or after
stretch's release.
When an Exim4 relay host lacks an IPv6 interface, mail
heisenbounces -- that is, it bounces sporadically, due
apparently to an obscure timeout or a race condition.
Full details are discussed here
[http://unix.stackexchange.com/q/308283/18202], where a user named
Rui F. Ribeiro cleverly discovers the fix.
LOGS AND CLUES
Here is a typical excerpt from my relay host's
/var/log/exim4/mainlog:
2016-09-11 18:31:30 H=dpc6935235115.direcpc.com (localhost) [69.35.235.115]
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 F=<[email protected]> rejected RCPT
<[email protected]>: relay not permitted
2016-09-11 18:32:46 1bj9Ya-0006aq-Jt <= [email protected]
H=dpc6935235115.direcpc.com (localhost) [69.35.235.115] P=esmtpsa
X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 A=plain_server:thb S=762
[email protected]
2016-09-11 18:32:46 1bj9Ya-0006aq-Jt gmail-smtp-in.l.google.com
[2607:f8b0:400d:c04::1b] Network is unreachable
2016-09-11 18:32:47 1bj9Ya-0006aq-Jt => [email protected] R=dnslookup
T=remote_smtp H=gmail-smtp-in.l.google.com [74.125.29.26]
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 1473618767
u126si8954672qkc.66 - gsmtp"
2016-09-11 18:32:47 1bj9Ya-0006aq-Jt Completed
In this log excerpt, two emails are sent. The first email
bounces at 18:31:30. The second email, sent to the same
recipient at 18:32:46, passes through. The recipient (which
in this instance happens to be a Gmail account I control)
receives the second email promptly. The first email however
never arrives.
The clue in this log is obscure. The aforementioned Mr.
Ribeiro is a fine detective to find it. Look at the third of
the five log lines, "Network is unreachable". The IP address
the line mentions is an IPv6 that belongs to the relay
recipient.
SO WHAT? WHO CARES?
But who cares? The email goes through to the relay
recipient's IPv4, instead, one second later, right?
Answer: Yes, the email does go through; but the *other* email
does not go through. What is confusing is that
the IPv6 "Network is unreachable" is reported only for the
email that does indeed go through, whereas the error turns out
to be more relevant with respect to the other email.
This is why this bug was so hard to diagnose. Some obscure
interaction between my nonexistent IPv6 interface and the
authenticator -- or some other interaction of the kind -- was
apparently instituting a timeout or race condition.
THE FIX
Once the bug is diagnosed, the fix is fairly
straightforward: if the relay host has no IPv6 interface, then
in /etc/exim4/exim4.conf.template, add "disable_ipv6 = true" to
the section main/01_exim4-config_listmacrosdefs. The neat way
to do this would probably be to add a suitable new parameter to
/etc/exim4/update-exim4.conf.conf, perhaps with "low" debconf
priority. On my own host, however, to save time, I have just
manually added the line and invoked "dpkg-reconfigure -phigh
exim4-config", bypassing update-exim4.conf.conf.
REMARKS
To be clear: this bug matters only if the relay host lacks
an IPv6 interface and (as I believe) the relay recipient has
an IPv6 interface. If you think about it, though, Exim4 should
probably not be exercising a nonexistent IPv6 interface,
anyway, should it? We never knew that this was an actual
problem, but now it turns out to be an actual problem, at least
for some users, or at any rate for Mr. Ribeiro and me.
Additional information: my relay server is plaintext password
protected after STARTTLS on port 587. (The X.509 certificate
happens to be a real one, not a snakeoil, but this is probably
not relevant to you.)
I have not tried the fix on sid, nor indeed have I verified the
bug on sid. Reviewing post-jessie changelogs however, I see no
entry that would already have fixed this. Thus, as far as I
know, the bug remains current.
If you have questions (whenever you get around to addressing
this bug, this year, next year, some year), let me know. I'll
be here. Meanwhile, users who discover this bug report and are
affected by the bug can straightforwardly implement the fix for
themselves.
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
All right. Actually, I think that this is a rather interesting
bug report, but it does not yet have a usable fix, after all.
After further tinkering, explained at [1], I once again believe
that I have a workaround to the heisenbounce, but time will
tell if I am right; and, anyway, a workaround is not a fix.
[1] http://unix.stackexchange.com/q/308283/18202
If a way occurs to me to express this bug in a manner that
allows you actually to do something about it, then I may reopen
this report. However, for now, let's close it.
Meanwhile, in the unlikely event that you are bored and have
time to kill, you might find the conversation linked above
interesting. That conversation might (or might not) tell you
one or two things you hadn't known about your own package.
Thank you for packaging Exim4.
signature.asc
Description: Digital signature
--- End Message ---
