https://bugs.exim.org/show_bug.cgi?id=1885
--- Comment #5 from Jeremy Harris <jgh146...@wizmail.org> --- Thanks for the additional analysis. Given that the smarthost relay server refuses to relay if un-authenticated (common practice: no open relays) it seems entirely reasonable that the client of a smarthost ought to require authentication on its outbound. Debian's point that some organisations regard their internal nets as being implicitly authenticated is reasonable, but perhaps having (yet another) question in their (admittedly already complicated) configurator might be possible to distinguish the two cases. This is important due to Exim's design decision to believe the peer when the peer gives a permanent (5xx) error for a message. We are very unlikely to change that. I think with regard to this BZ we should concentrate on how the authentication occasionally fails. It's not immediately obvious how the ipv6 issue on the outbound path from the smarthost could affect this. TLS problems between the client and smarthost might, if (good practice) plaintext auth is only done on encrypted connections. - Apparently that is that so here (auth requires crypt). Probably enforced by the server end only advertising then... - is tls required per. se. by the client? So the auth failing could be due to a lack of TLS, or at the SMTP AUTH stage itself. I assume the Exim authenticator has not been configured for special logging of fails, but that is a possible angle of investigation. 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. On the sat-link latency issue: this should not be a problem for the SMTP connections, unless you have turned any timeouts way down from standard; they're all much longer than even a geostationary-sat path time. I guess multiple DNS request roundtrips might be getting towards problem time totals - does the client have the server configured by name or by IP? -- 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/ ##