I just saw this PR, but forcing Wrapper means that even when starttls is turned on, TLS will be used anyway

But STARTTLS is just a TLS extension, so maybe the .tls(...) method affects only the TLS part without interfering with STARTTLS? I guess integration tests need to be set up to catch all those tricky behaviours.

The relay and starttls_relay methods are just convenience functions for setting the right variant of the Tls enum.

Tls::Required = We open the connection as plain and ask the server which extensions it supports. The server either supports STARTTLS and allows lettre to upgrade the initial plain text connection to TLS or we fail.
Tls::Wrapper = We open the connection directly with TLS, just like we would do with an https connection.

By doing .tls(Tls::Wrapper(tls)) you are invalidating the condition a few lines above where either TLS or STARTTLS is used based on the configuration, making lettre instead always use TLS.

I'm a Rust/TLS noob but I did not see any issue with starttls on the few tests I drove.

I didn't realized you are part of the lettre core team @paolobarbolini! Thanks for your precious help. So it means that there is no way to enable STARTTLS AND pass a custom TLS builder with dangerous_accept_* options?

So it means that there is no way to enable STARTTLS AND pass a custom TLS builder with dangerous_accept_* options?

It's totally possible. The change that needs to be done is passing .tls(...) the Tls::Required(tls) variant instead of the Tls::Wrapper(tls) variant when account.smtp_starttls() is true.

Awesome! @remche would you like to take care of this?

Will do asap