<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Le 29 mai 2020 à 11:17, Stuart Henderson <<a href="mailto:stu@spacehopper.org" class="">stu@spacehopper.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class="">On 2020-05-26, mj <<a href="mailto:lists@merit.unu.edu" class="">lists@merit.unu.edu</a>> wrote:<br class=""><blockquote type="cite" class="">Hi,<br class=""><br class="">On 25/05/2020 23:04, Voytek wrote:<br class=""><blockquote type="cite" class="">jumping here with a question, if I use 143 with STARTTLS, and, force<br class="">TLS/SSL in configuration, that's equivalent from security POV, isn't<br class="">it? and, same for 110 STARTTLS? Or am I missing something?<br class=""></blockquote>Interesting point, after some googling, I think you are right, and as <br class="">long as we have set "disable_plaintext_auth = yes" (and we have that) we <br class="">should be fine keeping 143 open. Right?<br class=""></blockquote><br class="">In the case of 143, nothing stops the client *sending* a plaintext login<br class="">request. Login may be denied, but the password is already leaked. Also<br class="">if you have only the server side (not the client side) deny plaintext<br class="">logins, a MITM can just strip off the STARTSSL capability from the server<br class="">response.<br class=""></div></div></blockquote><div><br class=""></div><div>And doing that it can as easily inject a LOGIN capability, making non-broken client also send the password in plain text. (Only broken client will send password if LOGIN is not present).</div><div><br class=""></div><div>That’s why this RFC exists: <a href="https://tools.ietf.org/html/rfc8314" class="">https://tools.ietf.org/html/rfc8314</a></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">In a setting where you want to protect the clients from accidentally<br class="">exposing secrets by misconfiguration, allowing only 993/995 (and 465 for<br class="">SMTP; 25/587 have the same problem) is the safe way.<br class=""></div></div></blockquote><div><br class=""></div><div>Port 25 is a special case and should never be used by client, but only for (unauthenticated) server to server communication.</div><div>There is no way to use implicit TLS for SMTP as the SMTP transport MX infrastructure has no way to specify a port.</div><div><br class=""></div><div>Client should always use the submission port (587, or 465 for submission over TLS).</div><br class=""></div><br class=""></body></html>