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.