STARTTLS is treated, as if it were an authentication method.

[stitch3210]

The design is a bit odd, when it comes to STARTTLS. It is listed in auth_method_t where it doesn't really belong. While it is useful to encrypt your credentials, that is not the primary point of it - it is supposed to encrypt the entire transaction, regardless of any authentication method.

This is not a huge problem in itself, but this effectively makes mailio's smtp client force an AUTH LOGIN, when using STARTTLS.

But SMTP relays or applications, that deliver SMTP messages directly to MX-relays perform STARTTLS all the time without any kind of authentication. This is also our use case and that flaw effectively limits our connections to unencrypted communication.

[karastojko]

Hi,

Sorry for the delayed reply.

Thanks for the explanation. Indeed, when I was thinking about making a separate smtps::start_tls() method or force it through the login method, the motivation was to switch from TCP to TLS socket as soon as possible. If no authentication is needed, can you set smtps::auth_method_t::NONE as the login method? If not, can you please point me to the RFC document or give more details (i.e. which SMTP commands are executed in your case)?

[stitch3210]

Hey, there, sorry as well - I'm currently a bit under pressure myself, so I can't participate in this as much as I'd like to. So... from my understanding, if I use smtps::auth_method_t::NONE, the client will immediately try to establish a TLS connection from the start. And in that case I can actually connect to a server without authentication - but I can't connect to a server, that starts off unencrypted. Our tests seem to confirm this. Only if I set STARTTLS as "auth method", can I defer TLS but I also am forced to use AUTH LOGIN, then.

I understand, that mailio was mostly made for sending mails to a dedicated relay server at someone's provider and for that scenario, this all should cover a lot of cases (though some servers won't accept AUTH LOGIN any more, but require OAUTH or CRAM).

Now, about STARTTLS: actually it wouldn't necessarily have to be a user's choice at all. STARTTLS implies ESMTP, which in turn implies, that the response to EHLO includes all commands, that are not minimally required, including STARTTLS (RFC 5321 §4.1.1.1 & §4.2). So mailio can decide, depending on the EHLO response, whether or not to perform STARTTLS. Currently, if I specify STARTTLS as method and the server doesn't support it (which I may not know in advance), the connection will fail.

It probably should only be the user's choice as far as this:

• don't ever attempt STARTTLS (because I know for some reason, that the handshake will fail, encryption not supported, whatever...)
• only send, if the server supports STARTTLS (some intermediate SMTP relays require this, to ensure no unencrypted traffic is sent).
• default: STARTTLS, if available, else unencrypted.

So the typical flow of commands would be: EHLO [email protected] Hi, so cool to see you! [email protected] Oh, wow, long time no see. 250-8BITMIME 250 STARTTLS STARTTLS .... etc...

And here - irrespective of what happened up to here and whether or not the connection is unencrypted, plain TLS, STARTTLS, ... do the selected authentication - or none (which is what our scenario would need).

According to the RFCs, as far as I understand it, STARTTLS may be issued at any time during the connection, so it's totally up to the client. But immediately after EHLO would be the ideal spot. Also, the server must not include STARTTLS in its EHLO response, if the connection already is encrypted, so you can rely on that keyword to be there only if STARTTLS is really possible.

I hope, I didn't confuse things more :-)

[karastojko]

@stitch3210 Removing the start tls as the login option is in the progress on this branch.

[karastojko]

The start tls option is set over the flag within the smtp class, it is not the login option anymore.

[stitch3210]

The start tls option is set over the flag within the smtp class, it is not the login option anymore.

Thanks!