https://bugs.exim.org/show_bug.cgi?id=1885
--- Comment #19 from Thaddeus H. Black <[email protected]> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
