On Tue, Feb 15, 2022 at 08:40:11AM -0700, Todd C. Miller wrote: > On Mon, 14 Feb 2022 20:05:30 +0100, Sebastien Marie wrote: > > > One aspect that I haven't verified for now is the difference between > > using "tls" (early initialisation) and not using it (late > > initialisation). I will try to look at it to ensure that the > > connection is always used with tls_config_verify(). > > TLS configuration for urls is a little tricky. We could parse the > url type for simple things like: > > action "relay-free" relay host "smtps://f...@smtp.free.fr" auth <secret> > > but if there is a table involved that will not work, which is why > I deferred the TLS setup. >
I looked at it a bit: it isn't still a 100% review (it would implied to me to fully read and understand the code path), but I have good confidence in the diff :) If you have a TLS connection, you had to use tls_configure(), and very few places calls it: - mta_session.c : for outgoing connection - smtp.c : for incoming connection only outgoing connection are implied here. So, as soon you have MTA_WANT_SECURE and no tls_required, tls_config_verify() will be called (and the connection will be properly verified). tls_required is directly modified only in parse.y (with "tls" or "tls no-verify" options). I didn't check for indirect modification (bzero or memset... but the 0 value would be RELAY_TLS_OPPORTUNISTIC, and it is this value since 2018, so I don't expect behaviour change here). MTA_WANT_SECURE is sets when the remote url starts with "smtps://" (RELAY_TLS_SMTPS) or "smtp+tls://" (RELAY_TLS_STARTTLS). So I assume there is no gap in the initialisation, and if you request a remote with "smtps://" or "smtp+tls://" you will always get a verified connection (assuming no existent hole in previous code). The diff is still ok semarie@ :) Thanks. -- Sebastien Marie
