Plaintext auth on ports 25/587 for local connections. Missing feature?

[eubyte]

It seems like chasquid does not support plaintext auth on ports 25/587 even for local connections (please see below). Lack of this ability may potentially be a problem for mail clients (e.g. Roundcube, RainLoop, etc.) installed on the same server, as well as other use cases where local authentication is required. I think it is highly desirable to have plaintext auth enabled for local connections by default, or some sort of configurable IP ranges.

Thank you for all you help!

--------------

telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.mydomain.tld ESMTP chasquid
ehlo localhost
250- mail.mydomain.tld - Your hour of destiny has come.
250-8BITMIME
250-PIPELINING
250-SMTPUTF8
250-ENHANCEDSTATUSCODES
250-SIZE 52428800
250-STARTTLS
250 HELP

[Alberto Bertogli]

On Wed, Feb 17, 2021 at 10:57:03AM -0800, eubyte wrote:
>It seems like chasquid does not support plaintext auth on ports 25/587 even
>for local connections (please see below). Lack of this ability may
>potentially be a problem for mail clients (e.g. Roundcube, RainLoop, etc.)
>installed on the same server, as well as other use cases where local
>authentication is required. I think it is highly desirable to have
>plaintext auth enabled for local connections by default, or some sort of
>configurable IP ranges.

A connection on any port will be able to authenticate as long as it
performs a starttls negotiation first.

Local services (msmtp, roundcube, rainloop) just need to negotiate TLS,
something that is quite common and well supported.

For example, I just found this documentation reference about Roundcube:
https://wiki.archlinux.org/index.php/Roundcube#Setting_Roundcube_up_for_use_with_an_IMAP/SMTP_server_that_only_allows_TLS_authentication


If you use "localhost" instead of your FQDN (e.g. "mydomain.com") then
you need to disable TLS verification on the client side (e.g.
"verify_peer" option in Roundcube). This is because the server certs
will be for "mydomain.com" and not "localhost" so there's a mismatch.


I understand this means extra configuration options on the clients if
"localhost" is used instead of FQDN, which I know it's a bit of extra
hassle to set up.

But the complexity that would be introduced by allowing non-encrypted
connections over localhost to do authentication is IMO not worth it,
considering how sensible this part of the code is.

Given there are easy ways to configure this properly on the client side,
and that it's fairly common to do so (I could find answers and examples
for the mentioned software fairly quickly), I rather keep things simple
and more secure.

I hope this helps!

Thanks,
Alberto