Support the LOGIN method to expand client compatibility

[erjoalgo]

Some clients do support TLS but use the LOGIN method, where the client waits for a password prompt before sending the password, as opposed to the currently-supported PLAIN method, where the client sends both username and password as part of a single request. This minimal change attempts to support the LOGIN method by parsing credentials, and then converting them into a PLAIN-like auth string.

[albertito]

Hi! Thanks a lot for sending this, and to @ThinkChaos for the review!

I just wanted to let you know that I am travelling with limited connectivity, sorry for the delay! I hope to get to this tomorrow!

[albertito]

I just did a first pass review, overall it looks good, and most of the suggestions are just around reordering code, but I hope it's nothing too problematic.

This still would need a lot of testing but I'm happy to do that part.

All that said, I have to wonder about the benefit of implementing this method vs. the complexity added.

The LOGIN method has been obsolete (IANA SASL mechanisms) for decades. As far as I can tell it was never really standarized, draft-murchison-sasl-login-00.txt is the closest it got.

And it is basically a more complex variant of the PLAIN method (which is a solid standard and widely used).

So I wonder how many additional "reasonably used clients" this would allow chasquid to interoperate with.

Do you know of any besides ssmtp? If ssmtp is the only one we can find (that is reasonably used), then it might be more practical to send a patch adding PLAIN support to it instead?

What do you think?

Thanks again!

PS: I think the other two patches are useful in any case and I'm inclined to merge them regardless, but let's focus on the LOGIN method first just for clarity of the conversation!

[erjoalgo]

Sorry, I've been a little busy, I will take a look next week.

Basically, to test my setup I looked for a few SMTP clients packaged on debian and I initially couldn't get any of them to work out of the box with my chasquid server, so I suspected there was something missing either with my setup or with chasquid, or with my DNS, etc. I tried msmtp, sendemail, and ssmtp. I picked one of these clients. the first one happened to be ssmtp, looked at the source and noticed the problem was the PLAIN vs LOGIN auth, which I fixed and manually tested. Later, I tried fixing msmtp and noticed that it had failed not because of a fundamental incompatibility but because I had failed to specify a number of specific flag values, including: --auth=plain, --tls=on, and --tls-starttls=off. I was never able to get sendemail to work even after installing the requied perl TLS libraries.

I do not know how many clients prefer LOGIN over PLAIN, but in an ideal world most clients should work with most servers out of the box without the need for users to spend too much time tweaking or debugging, especially since most users just care about having a working email server and client, but are probably not willing to dig down and study the sources and compare the server and client to determine why it's not working. If chasquid can be a server that "just works" under most circumstances and make things easy for users and clients then I think it can become even more useful and powerful than it is already.

[albertito]

Sorry, I've been a little busy, I will take a look next week.

Of course, no worries, and there's nothing to apologize for!

Basically, to test my setup I looked for a few SMTP clients packaged on debian and I initially couldn't get any of them to work out of the box with my chasquid server, so I suspected there was something missing either with my setup or with chasquid, or with my DNS, etc. I tried msmtp, sendemail, and ssmtp. I picked one of these clients. the first one happened to be ssmtp, looked at the source and noticed the problem was the PLAIN vs LOGIN auth, which I fixed and manually tested. Later, I tried fixing msmtp and noticed that it had failed not because of a fundamental incompatibility but because I had failed to specify a number of specific flag values, including: --auth=plain, --tls=on, and --tls-starttls=off. I was never able to get sendemail to work even after installing the requied perl TLS libraries.

It's a minor point overall, but for what it's worth, msmtp works fine with auth=on as it can negotiate the method, which is what most clients would do. This is also covered in integration tests (many of them use msmtp).

I've never used sendemail but it seems to support PLAIN. More on this below.

I do not know how many clients prefer LOGIN over PLAIN, but in an ideal world most clients should work with most servers out of the box without the need for users to spend too much time tweaking or debugging, especially since most users just care about having a working email server and client, but are probably not willing to dig down and study the sources and compare the server and client to determine why it's not working. If chasquid can be a server that "just works" under most circumstances and make things easy for users and clients then I think it can become even more useful and powerful than it is already.

I understand this is a frustrating experience, and I really appreciate you sending a patch to make things better.

In practice, I do my best to balance ease of use and flexibility with security, maintainability and reliability. Sometimes the tradeoffs are obvious, but sometimes they are not.

To me, in this case, unfortunately I am not sure the benefits outweigh the costs in terms of complexity.

Another example of a similar case is that chasquid only supports authentication over TLS, even if the client is in localhost, where it could be argued it provides a negligible value. This means client setup on localhost is more complicated, but has the upside of making it less likely to have security bugs around authentication.

However, it is clear from your experience that client set up can be non-intuitive and require more research/trialling than it should.

So how about we add a "Clients" document, where we list different clients and have brief and practical configuration examples, to reduce that friction? And it could include a section on unsupported clients as well. That can help offset some of the difficulty, and cover other aspects you faced, in addition to the login method part.

I'd be happy to write a draft and iterate on that with you to help future users.

What do you think?

Thanks again!

[erjoalgo]

Thanks for the thorough reply. I disagree that this change is not worth implementing. I believe LOGIN is a valid SMTP authentication method which valid SMTP clients may choose to employ, and I think it's possible to support it for all clients without compromising security. I do appreciate and respect your work developing and maintaining chasquid, and I respect your opinion so I am closing this PR. I do think providing a client's section would be useful, though I think it would be easier for users if compatibility could be improved on the server side.

[albertito]

Thanks for the thorough reply. I disagree that this change is not worth implementing. I believe LOGIN is a valid SMTP authentication method which valid SMTP clients may choose to employ, and I think it's possible to support it for all clients without compromising security. I do appreciate and respect your work developing and maintaining chasquid, and I respect your opinion so I am closing this PR. I do think providing a client's section would be useful, though I think it would be easier for users if compatibility could be improved on the server side.

Thank you so much for your understanding, even though we disagree. I know it is not great to have a change rejected, and I'm sorry about that, but still really appreciate it and the very useful discussion around it.

I would like to merge the other two patches, if that's okay with you?

Also, opened #48 to track the documentation improvements around setting up clients.

Thanks again!