My understanding is that RFC compliance is highly variable in email client-server relationships. This is because servers tend to have preexisting relationships with clients such that servers can dictate configurations. Therefore RFC compliance isn't important for interoperability.
Using STARTTLS over port 143 is perfectly secure if it is "required." The pertinent RFC's is 2595 (June 1999), which I just reviewed. It specifies (and favors) STARTTLS on port 143 and frowns upon the dedication of port 993 for TLS. The exact wording is: '/Separate ports imply a model of either "secure" or "not secure."/' It is interesting that that concept was frowned upon back then because it has definitely become favored today. Being in a nebulous/unknown security state leads to false assumptions which lead to security failure. So per the RFC, I stand corrected: port 143 is the designated STARTTLS port. That makes logical since because the initial handshakes of TLS and STARTTLS are incompatible, whereas plain-text and STARTTLS both start out the same. However, going as far back as using Eudora in the late 90's, I've seen massive variability in IMAP/POP configurations. When the server gets to dictate configuration to the client in advance, anything goes. For example, here is Thunderbird's port 993 options: Note that STARTTLS is an option on 993 (along with "none") and that there is no setting for "required" versus "optional". I've been using Thunderbird for about 10 years, and I'm pretty sure that prior versions had a setting for "required" or "optional" for STARTTLS. Eudora definitely had it. There is a reasonable chance that the Thunderbird developers removed the setting and that it silently uses "required". But if so, the end result is an ambiguous security setting from the perspective of admins/users. That is currently unacceptable. The IMAP/POP server might be configured for required STARTTLS, but how would the user know that? Transparency = good, ambiguity = bad. That being said, here is Thunderbird's setting for submission on port 465: Clearly "None" and "STARTTLS" are not supposed to be supported on port 465. I imagine they include those options because enough server admins want them. Again, the clients simply do as their server admins dictate. Good question because it prompted me to review the RFC's. The password encryption schemes (like digest-md5) are a concept which predates authentication over an encrypted channel. The problem with digest-md5 is that the md5 hash is considered broken and completely insecure for such purposes. The new mantra is to be explicitly secure or insecure; therefore use of weak security to achieve a nebulous security situation is slowly becoming outlawed. Here is the wikipedia article about digest-md5: https://en.wikipedia.org/wiki/Digest_access_authentication If you can guarantee an encrypted session (which is always the case with TLS), then just use PLAIN auth and ignore the password encryption schemes all together. The advantage of this is that PLAIN will never require reconfiguration because it has become "broken". Again, I hope with is helpful (and accurate). -Andy On 8/14/2018 1:10 AM, Peter Peltonen wrote: > Thanks Andy. Just to be sure on this: I had the impression that > STARTTLS could be used also with port 143? At least reading > https://wiki.dovecot.org/SSL indicates so: > > "Clients using STARTTLS work by connecting to the regular unencrypted > port and immediately issue a STARTTLS command, after which the session > is encrypted." > > So it shouldn't matter if I use 143 or 993 as a port? > > My users should all use TLS (configured to their clients). I'm still > wondering about the DIGEST-MD5: what is that auth mechanism for and > why did my toaster conf use it? Anything bad that can happen by > removing it? And what is the difference between PLAIN and LOGIN auth > mechanisms? Are there client configs For Outlook / Thunderbird / Apple > Mail that could be broken by this? > > Best, > Peter > > > > On Tue, Aug 14, 2018 at 11:25 AM, Andrew Swartz <awswa...@acsalaska.net> > wrote: >> Peter, >> >> If you are using ports 110/143, which are clear-text, then you should >> switch to 993/995 (if possible, of course). >> >> Ports 993/995 are never intentionally clear-text; they are either TLS or >> STARTTLS. Many servers/clients can be configured for either, but they >> cannot be configured for both because the initial protocol sequences are >> incompatible. >> >> If 993/995 are configured for TLS, you can use PLAIN auth method and not >> give it another thought. >> >> But if configured for STARTTLS, it must be set to "require" STARTTLS >> rather than just "if available". If you can "require" STARTTLS, then >> PLAIN auth is secure because the login cannot not be sent unencrpyted. >> >> But if the connection is configured as "STARTTLS if available", then >> failure to initiate the STARTTLS will result in continuing with a clear >> text session. In this scenario, a PLAIN auth would be very dangerous. >> >> Hope this helps. >> >> -Andy >> >> >> On 8/13/2018 11:43 PM, Peter Peltonen wrote: >>> Thanks for the suggestions! >>> >>> So if I have only plain and login auth mechanisms enabled, what does >>> that mean in practice security wise? >>> >>> Any ideas why the error is happening sometimes but not always and why >>> aut_cache settings would fix the problem? Is it related to caching >>> credentials for different devices / clients for same account? >>> >>> Best, >>> Peter >>> >>> On Tue, Aug 14, 2018 at 5:52 AM, Eric Broch <ebr...@whitehorsetc.com> wrote: >>>> I'd remove DIGEST-MD5 from 'auth_mechanisms'. >>>> >>>> >>>> >>>> On 8/13/2018 3:01 PM, Peter Peltonen wrote: >>>>> I have a user with Outlook 2016 having this error appearing in the >>>>> Dovecot logs and not being able to login when it occurs >>>>> >>>>> The strange thing is that if I restart dovecot then the Outlook can >>>>> login and no error: >>>>> >>>>> method=DIGEST-MD5, rip=xxx, lip=yyy, mpid=23280, TLS >>>>> >>>>> What I have for auth mechanisms in toaster.conf is: >>>>> >>>>> auth_mechanisms = plain login digest-md5 >>>>> >>>>> I thought it was a dovecot cache issue and I changed >>>>> >>>>> cache_key=%u >>>>> >>>>> to >>>>> >>>>> cache_key=%u%r >>>>> >>>>> but the problem reappeared after a week. >>>>> >>>>> This is an old QMT installation on COS5. >>>>> >>>>> Best, >>>>> Peter >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>>>> >>>> -- >>>> Eric Broch >>>> White Horse Technical Consulting (WHTC) >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>> >>> >> -- >> Andrew W. Swartz, MD >> Departments of Emergency Medicine, Family Medicine, and Surgery >> Yukon-Kuskokwim Delta Regional Hospital >> Bethel, Alaska >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > -- Andrew W. Swartz, MD Departments of Emergency Medicine, Family Medicine, and Surgery Yukon-Kuskokwim Delta Regional Hospital Bethel, Alaska
smime.p7s
Description: S/MIME Cryptographic Signature
