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

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:

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).


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
> 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 <> 
> 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 <> 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:
>>>>> For additional commands, e-mail:
>>>> --
>>>> Eric Broch
>>>> White Horse Technical Consulting (WHTC)
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> --
>> Andrew W. Swartz, MD
>> Departments of Emergency Medicine, Family Medicine, and Surgery
>> Yukon-Kuskokwim Delta Regional Hospital
>> Bethel, Alaska
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Andrew W. Swartz, MD
Departments of Emergency Medicine, Family Medicine, and Surgery
Yukon-Kuskokwim Delta Regional Hospital
Bethel, Alaska

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to