https://bugs.exim.org/show_bug.cgi?id=1885
--- Comment #19 from Thaddeus H. Black <thb@???> ---
Jeremy Harris suggested:
> The apparent randomness and/or first-try-only behaviour might be affected by
history maintained at either end, notably in the hints databases. For test
purposes I suggest wiping them before each test ('exim -bP spool_directory',
append '/db/*', prepend 'rm '). If you possibly can, run one or both ends
with debug enabled ('-d+all'). On the server this needs adding to your normal
daemon commandline, run from a terminal with stderr captured (I use cmdlines
like 'service exim stop && exim -d+all -bd 2>&1 | tee log'). On the client
it depends whether you're sending mail from the cmdline or via a daemon, but
either way we want the debug activated (and captured) from the relevant exim
process.
Later, I wrote:
> Once I have isolated an instance of a heisenbounce and have debug-logged it on both ends, I will post the logs; but this is a patient business. I have not yet learned to produce bounces at will, but must wait for bounces to occur on their own, perhaps twice a week.
I have isolated an actual instance of a heisenbounce and, per your advice, have
debug-logged it on both ends. See attachments 928, 929 and 930.
Attachment 928 logs the bounce on the client's end. Attachment 929 logs the
next relay, which succeeded, also on the client's end. Attachments 928 and 929
are similar until line 341 of each file:
Attachment 928, line 341: 19:44:50 5467 fully qualified name = example.com
Attachment 929, line 341: 19:46:11 5503 fully qualified name =
smtp.example.com
A few lines later, attachment 928 fails to authenticate.
On the client, the file /etc/exim4/passwd.client reads:
smtp.example.com:thb:mypassword
So, perhaps the problem is some weird DNS effect. A workaround now seems
obvious -- I can add this line to /etc/exim4/passwd.client:
example.com:thb:mypassword
I will now try this. However, I have no idea why a problem should exist to be
worked around, nor whether the problem lies within Exim or without.
In case it isn't obvious, I have scrubbed (or tried to scrub) passwords,
sensitive information and spam targets from the logs. For instance,
example.com is really thblackelectric.com, and mypassword is, well, my
password.
* * *
Earlier in this bug log, Jasen Betts helped me to improve my Exim
configuration. At the time, I believed that Jasen's improvement would banish
my problem. For information, however, Jasen's improvement did not banish my
problem.
Of course, Jasen was right. I have permanently retained his suggested
improvement! It just turns out that the thing improved was apparently not
related to this bug -- a fact which, of course, Jasen and I had no way to know
until I had actually implemented his fix.
--
You are receiving this mail because:
You are on the CC list for the bug.
