https://bugs.exim.org/show_bug.cgi?id=1885
--- Comment #5 from Jeremy Harris <jgh146exb@???> ---
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.
