dovecot - Jul 2020 - SV: Outlook vs Thunderbird

Am 07.07.2020 um 08:07 schrieb Mark Constable:
> 
> FWIW I meant if the client is Windows7/old-Outlook then changing either
> 993/SSL or 143/STARTTLS to 143/NONE could help pick up the mail. We had
> to do this for a 100 or so clients a few months ago after upgrading to
> Ubuntu 20.04.
Curious, what's the rationale behind that move? Is it because that old 
beast of Outlook does not have the capabilities modern TLS/STARTTLS 
implementations require regarding TLS minimal version and ciphers?

But plaintext auth for mail access, seriously?

Alexander

Plaintext access is no problem if the connection is secured via other means -
for example internal network or VPN.
If the IMAP server cannot be accessed from the outside, and the traffic
don't travel over wifi or public networks, no danger.

-----Ursprungligt meddelande-----
Fr?n: dovecot-bounces at dovecot.org <dovecot-bounces at dovecot.org> F?r
Alexander Dalloz
Skickat: den 7 juli 2020 18:05
Till: dovecot at dovecot.org
?mne: Re: Outlook vs Thunderbird

Am 07.07.2020 um 08:07 schrieb Mark Constable:
> 
> FWIW I meant if the client is Windows7/old-Outlook then changing 
> either 993/SSL or 143/STARTTLS to 143/NONE could help pick up the 
> mail. We had to do this for a 100 or so clients a few months ago after 
> upgrading to Ubuntu 20.04.
Curious, what's the rationale behind that move? Is it because that old beast
of Outlook does not have the capabilities modern TLS/STARTTLS implementations
require regarding TLS minimal version and ciphers?

But plaintext auth for mail access, seriously?

Alexander


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200707/68d73509/attachment-0001.p7s>

Am 07.07.2020 um 18:11 schrieb Sebastian Nielsen:
> Plaintext access is no problem if the connection is secured via other means
- for example internal network or VPN.
> If the IMAP server cannot be accessed from the outside, and the traffic
don't travel over wifi or public networks, no danger.
First of all, please keep answers on the mailing list only. Obviously I 
am subscribe and I don't need to get your reply twice, by list 
distribution and in addition to my personal address.

And top-posting is another thing you should avoid.

To your answer: I disagree and see that you have a false understanding 
of security. You want service protocol encryption (here for IMAP or 
POP3) from end to end. Nothing which breaks up encryption in between.

That's valid for any size of environment. You may judge the risk is 
tolerable in case you run you own small setup where you are the only 
user. But I replied to Mark's note where he wrote about ~100 clients. So 
he either running an IMAP service for clients - where it is 
inresponsible to not teach them about security and instead lower the 
protection to none - or administering a company network for which end to 
end service encryption is a must too.

Alexander

On 07 Jul 2020, at 10:11, Sebastian Nielsen <sebastian at sebbe.eu>
wrote:
> If the IMAP server cannot be accessed from the outside, and the traffic
don't travel over wifi or public networks, no danger.
No, not no danger, but certainly less danger. The most obvious dangers even in a
closed environment is if someone can monitor the network, they gather all the
passwords. Of course, more common albeit harder is for a bad actor to gain
access inside your network.

It is simple enough to use encrypted connections and good password
policies<1> everywhere that there is really no reason to not do so. And
supporting EOLed software, especially when it's little more than an attempt
to save a little money, is a foolish reason to not use security IMO.

As soon as you start thinking that your network is inviolate, you find yourself
in a Sony situation where everything on your network has been taken by someone
else. Just because someone gets in is no reason to give them the keys to
everything you have.

<1> actual good policies, not the idiotic ones most corporations use, of
course.

On 8/7/20 2:04 am, Alexander Dalloz wrote:
>> FWIW I meant if the client is Windows7/old-Outlook then changing
>> either 993/SSL or 143/STARTTLS to 143/NONE could help pick up the
>> mail. We had to do this for a 100 or so clients a few months ago
>> after upgrading to Ubuntu 20.04.
> 
> Curious, what's the rationale behind that move? Is it because that
> old beast of Outlook does not have the capabilities modern
> TLS/STARTTLS implementations require regarding TLS minimal version
> and ciphers?
It involved Windows7 customers and older Apple device users.

Recent versions of Thunderbird on Win7 still worked fine but even
Outlook 2016 on Win7 could no longer pick up mail with SSL enabled.
It happened after a Ubuntu server update to Dovecot and Openssl about
3 or 4 months ago.
> But plaintext auth for mail access, seriously?
Tell me about it! We spent YEARS getting these same folks to change to
secure settings (some of them have been with us for 20+ years) so it
was heartbreaking to contact each one of them and talk them through
disabling SSL.

I spent a week trying every cypher combination I could find via Google
for Dovecot but with the phone going off the hook from complaints by
customers not being able to pick up their mail. We had to respond with
some solution so, after a week, disabling SSL was very reluctantly the
only option left. We lost ~40 customers to outlook.com because of this.

Actually, there is a regedit "trick" for Win7 but that is beyond the
ability of our customers to apply, and that doesn't help the older
Apple device users.

FWIW.

>>Actually, there is a regedit "trick" for Win7 but that is
beyond the ability of our customers to apply, and that doesn't help the
older Apple device users.
You could build a .reg file with the trick inside, and then distribute it to
your users. However it wont solve the Apple problem.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: S/MIME Cryptographic Signature
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20200708/fe03b52a/attachment.p7s>

On Wed, Jul 08, 2020 at 12:05:55PM +1000, Mark Constable
wrote:
> I spent a week trying every cypher combination I could find via Google
> for Dovecot but with the phone going off the hook from complaints by
> customers not being able to pick up their mail. We had to respond with
> some solution so, after a week, disabling SSL was very reluctantly the
> only option left. We lost ~40 customers to outlook.com because of
> this.
Ouch.  But does outlook.com not require TLS?  (I don't currently have an
outlook.com account.)

If so, then why would customers be able to solve their problem by moving
to outlook.com?  Maybe by using outlook.com's webmail interface, I
guess, but you could presumably compete with this by offering
Squirrelmail or Roundcube.

Yet another possible workaround for customers using email clients or
operating systems that don't speak recent versions of TLS is to have
them install stunnel on their PC, or else to send them a box (e.g.
Raspberry Pi) running stunnel that they can put on their LAN/WLAN:

https://joewein.net/blog/2018/07/04/outlook-express-error-0x800ccc0b-and-the-end-of-tls-1-0-deprecated-ssl-protocol/

https://en.wikipedia.org/wiki/Stunnel

Of course, the main problem with sending a box is that it would
periodically require software updates & reboots.  If you already have a
routine for upgrading software on boxes on customer premises, then
include the boxes in that routine; otherwise, it's a headache.

Also, the stunnel approach would not help for non-jailbroken iOS devices
except while they are downstream of an stunnel box.  So, OK over the
WLAN but no good while on mobile data.

Anyway, good luck!

-- 
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?

()  ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\  file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.