TLS problem with iOS 9 Mail clients
Hi everyone, recently I migrated my mail server from an Ubuntu 16.04 box to an Ubuntu 20.04 box, so from dovecot 2.2.22 to 2.3.7.2, and to openssl 1.1.1.f. While everything else works fine, I have one important user stuck on an iOS 9 device that I need to support for a while longer, with which the IMAP TLS handshake keeps failing. From the logs: TLS handshaking: SSL_accept() failed: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol I didn’t find a debug option to dump the TLS handshake details, so I analyzed a packet dump and found the following capabilities and cipher suites offered by the client: Transport Layer Security TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 149 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 145 Version: TLS 1.0 (0x0301) Random: 5fef787ac06215d0a4edefd17602fadf409ab0512e04e62ade6192f2499f4896 Session ID Length: 0 Cipher Suites Length: 50 Cipher Suites (25 suites) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 54 Extension: server_name (len=19) Type: server_name (0) Length: 19 Server Name Indication extension Extension: supported_groups (len=8) Extension: ec_point_formats (len=2) Type: ec_point_formats (11) Length: 2 EC point formats Length: 1 Elliptic curves point formats (1) EC point format: uncompressed (0) Extension: status_request (len=5) Type: status_request (5) Length: 5 Certificate Status Type: OCSP (1) Responder ID list Length: 0 Request Extensions Length: 0 Extension: signed_certificate_timestamp (len=0) Type: signed_certificate_timestamp (18) Length: 0 I already tweaked the dovecot-ssl config down with "ssl_min_protocol = TLSv1” and included ECDHE-ECDSA-AES256-SHA in the cipher list, but the client still won’t connect. Does anyone have an idea what else I could try? Thanks Maik
Re: TLS problem with iOS 9 Mail clients
> On 01 Jan 2021, at 17:57, @lbutlr wrote: Apologies, my Internet connection seems to have died for about an hour and the message sent out several times when it started to come back up. -- Footnote on the High Energy Magic building: It was here that the thaum, hitherto believed to be the smallest possible particle of magic, was successfully demonstrated to be made up of resons (lit: 'Thing-ies) or reality fragments. Currently research indicates that each reson is itself made up of a combination of at least five 'flavours', known as 'up', 'down', 'sideways', 'sex appeal' and 'peppermint'.
Re: TLS problem with iOS 9 Mail clients
On 01 Jan 2021, at 16:01, Maik Musall wrote: > recently I migrated my mail server from an Ubuntu 16.04 box to an Ubuntu > 20.04 box, so from dovecot 2.2.22 to 2.3.7.2, and to openssl 1.1.1.f. While > everything else works fine, I have one important user stuck on an iOS 9 > device that I need to support for a while longer, with which the IMAP TLS > handshake keeps failing. From the logs: macOS 9 does not support any currently valid and support TLS version and cannot communicate on the Internet securely. > Does anyone have an idea what else I could try? Have them get an iPad for mail? I don't think they can even use secure webmail. -- All he [Vimes] knew was that you couldn't hope to try for the big stuff, like world peace and happiness, but you might just about be able to achieve some tiny deed that'd make the world, in a small way, a better place. Like shooting someone.
Re: TLS problem with iOS 9 Mail clients
On 01 Jan 2021, at 16:01, Maik Musall wrote: > recently I migrated my mail server from an Ubuntu 16.04 box to an Ubuntu > 20.04 box, so from dovecot 2.2.22 to 2.3.7.2, and to openssl 1.1.1.f. While > everything else works fine, I have one important user stuck on an iOS 9 > device that I need to support for a while longer, with which the IMAP TLS > handshake keeps failing. From the logs: macOS 9 does not support any currently valid and support TLS version and cannot communicate on the Internet securely. > Does anyone have an idea what else I could try? Have them get an iPad for mail? I don't think they can even use secure webmail. -- All he [Vimes] knew was that you couldn't hope to try for the big stuff, like world peace and happiness, but you might just about be able to achieve some tiny deed that'd make the world, in a small way, a better place. Like shooting someone.
Re: TLS problem with iOS 9 Mail clients
On 01 Jan 2021, at 16:01, Maik Musall wrote: > recently I migrated my mail server from an Ubuntu 16.04 box to an Ubuntu > 20.04 box, so from dovecot 2.2.22 to 2.3.7.2, and to openssl 1.1.1.f. While > everything else works fine, I have one important user stuck on an iOS 9 > device that I need to support for a while longer, with which the IMAP TLS > handshake keeps failing. From the logs: macOS 9 does not support any currently valid and support TLS version and cannot communicate on the Internet securely. > Does anyone have an idea what else I could try? Have them get an iPad for mail? I don't think they can even use secure webmail. -- All he [Vimes] knew was that you couldn't hope to try for the big stuff, like world peace and happiness, but you might just about be able to achieve some tiny deed that'd make the world, in a small way, a better place. Like shooting someone.
Re: TLS problem with iOS 9 Mail clients
On 01 Jan 2021, at 16:01, Maik Musall wrote: > recently I migrated my mail server from an Ubuntu 16.04 box to an Ubuntu > 20.04 box, so from dovecot 2.2.22 to 2.3.7.2, and to openssl 1.1.1.f. While > everything else works fine, I have one important user stuck on an iOS 9 > device that I need to support for a while longer, with which the IMAP TLS > handshake keeps failing. From the logs: macOS 9 does not support any currently valid and support TLS version and cannot communicate on the Internet securely. > Does anyone have an idea what else I could try? Have them get an iPad for mail? I don't think they can even use secure webmail. -- All he [Vimes] knew was that you couldn't hope to try for the big stuff, like world peace and happiness, but you might just about be able to achieve some tiny deed that'd make the world, in a small way, a better place. Like shooting someone.
Re: Using dovecot with RoundCubeMail - where is the information for new mail in (blue coloured) directories?
Scott, On 2020-12-22 02:48, Scott Ruckh wrote: On 2020-12-20 17:37, Philip Rhoades wrote: @lbutlr, On 2020-12-21 00:43, @lbutlr wrote: On 20 Dec 2020, at 04:05, Philip Rhoades wrote: I guess that is what it seems to look like to me as well - but what does that mean for what I am trying to do? - ie reset the blue folder highlight arbitrarily? Sound like the Roundcube style choices are outside th purview of dovecot. Hmm . . the first response I got here was that it was definitely an IMAP thing . . I think he was unclear about the actual problem . . I will try the RCM forum . . Thanks, P. I am not sure I have understood this thread completely, but I am running dovecot/RoundCube. If a folder has new messages, then it has a badge that is dark blue (with the theme I am using) with the number of un-read messages. Otherwise it has a badge that is light-blue to indicate un-read messages only. Folders with no badges have zero un-read messages. So there is definitely a distinction for "new" messages. Although it looks like the issue is with RCM, I attach the partial screen capture I sent before so you can see what I am talking about. P. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: p...@pricom.com.au
Re: LDA ignores virtual mailbox settings
Hi Piotr, On Fri, Jan 01, 2021 at 05:59:42PM +0100, Piotr Auksztulewicz wrote: > Please note that local.conf is included by include_try directive. > Check local.conf permissions versus userid running deliver, configured > in master.cf. If it can't read local.conf, it will simply ignore it. I was somehow not aware of this problem, but this solved it nicely. There are some problems, still, but now things "almost work". Thanks a lot, Toni
Re: LDA ignores virtual mailbox settings
On Fri, Jan 01, 2021 at 03:45:14PM +, Toni Mueller wrote: > I found that there may be a problem in merging configuration directives. > In Debian, the main config file is /etc/dovecot/dovecot.conf. This > includes some snippets in /etc/dovecot/conf.d, and, at last, includes > /etc/dovecot/local.conf. > > In local.conf, I have different values for that, but only if I comment > them out in 10-mail.conf, I get LDA to try to deliver to the directory > where it should deliver. Therefore, I assume that later directives are Please note that local.conf is included by include_try directive. Check local.conf permissions versus userid running deliver, configured in master.cf. If it can't read local.conf, it will simply ignore it. -- Piotr "Malgond" Auksztulewicz firstn...@lastname.net
Re: LDA ignores virtual mailbox settings
Hi,
thanks to all the people who tried to help me. I have made one more
step into the right direction and wanted to share my findings.
To recap, LDA pulls the right data from userdb, then ignores it and
tries to deliver to the system default maibox location at /var/mail:
On Sun, Dec 27, 2020 at 04:19:35PM +, Toni Mueller wrote:
> 16:04:16 dovecot: auth: Debug: userdb out:
> USER#0111#011u...@example.com#011home=/path-to-mailboxen/example.com/user#011uid=12345#011gid=12345#011quota_rule=*:storage=0
>
> ^^
>
> This shows that the database lookup works. The intended effect should be
> that the message is delivered to
>
> /path-to-mailboxen/example.com/user/Maidir/new
>
>
> 16:04:16 dovecot: lda(u...@example.com)<5291>: Error:
> Mailbox INBOX: open(/var/mail/u...@example.com) failed: Permission denied
> (euid=12345(mailbox) egid=12345(mailbox) missing +w perm: /var/mail, we're
> not in group 8(mail), dir owned by 0:8 mode=0775)
>
> ^^
>
> And this shows that dovecot-lda just ignores the result.
1. Directive merging:
I found that there may be a problem in merging configuration directives.
In Debian, the main config file is /etc/dovecot/dovecot.conf. This
includes some snippets in /etc/dovecot/conf.d, and, at last, includes
/etc/dovecot/local.conf.
In /etc/dovecot/conf.d/10-mail.conf, there are these two statements:
mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_privileged_group = mail
In local.conf, I have different values for that, but only if I comment
them out in 10-mail.conf, I get LDA to try to deliver to the directory
where it should deliver. Therefore, I assume that later directives are
not overwriting earlier directives, but "first wins" is an uncommon
strategy - usually, it's "last wins". I'm not sure whether this is a bug
or not, though, but a quick search did not reveal how things are
supposed to be.
2. Wrong mailbox settings:
I want to deliver to maildir and have these settings: Globally, ie,
outside of all "blocks" ( [] { ... }), I have
mail_location = maildir:~/Maildir:INBOX=maildir:~/Maildir
In addition to that, I have this:
namespace inbox {
inbox = yes
location = maildir:~/Maildir
}
But Dovecot wrote the mail to a file in mbox format, and the file being
at ~/mail/inbox, with ~ being the home dir as taken from the SQL
database.
3. Autocreate fails:
I now have this for LDA and IMAP:
cut
protocol imap {
mail_plugins = autocreate quota imap_quota mail_log trash virtual notify
mail_max_userip_connections = 10
}
protocol lda {
mail_plugins = autocreate quota virtual mail_log trash notify
...
}
cut
In the first instance, the home from the database was created by
Dovecot, but then I moved it aside, so as to have Dovecot create a new
one. But now I get this, even after lifting the plugin settings of LDA
to the global scope:
Jan 1 15:07:52 dovecot: lda(u...@example.com)<13951>:
Fatal: Namespace '': Mail storage autodetection failed with
home=/path-to-mailboxen/example.com/user
Setting 'mail_location', as was suggested numerous times on the
Internet, does not seem to have the desired effect, and I only have the
'inbox' namespace, anyway.
Any ideas, please?
TIA!
Cheers,
Toni
Re: migration from 2.0.16
Hi, On Thu, Dec 17, 2020 at 03:56:45PM +0100, Barbara M. wrote: > Debian 10 is EOL on 2022 this may be true, but (1) you can probably expect Debian to have LTS for this - they had for the last few distributions, extending their livetimes to more than 5 years at least (I think Jessie was pulled recently), and upgrades are usually smooth. > Ubuntu LTS seems a solution, but I hadn't ever used it (I may be wrong, but > in the past Canonical don't inspire me to much trust). Me too. IMHO, Debian is the better choice, due to better QA and more effort in backwards compatibility and upgradability. Also, Debian is less driven by commercial considerations, and at least not directly dependend on company policies. A happy new year all around! Enjoy, Toni
Re: Initial Replication
Thanks Ross! Your instructions worked like a charm. I’ve been monitoring both sides for days and everything looks great. Sent from my iPhone > On Dec 29, 2020, at 15:30, Marc Roos wrote: > > > > Hi David, > > Afaik you have to put the 'old' emails before replicating on both, > because replicating only works on new arriving. > > I just migrated to a server on a different platform keeping same os and > dovecot version. One namespace had mbox storage which on the new server > became mdbox. > > For the mbox -> mdbox namespace I used this > > doveadm backup -f -n inbox -F /root/backup-accounts.txt > tcp:mailXX.local:542 > > Test first with one account, depending on the permissions of the > directories on the destination, dovecot will create all the files. > > I had a 2nd namespace that I needed to migrate that was already in > mdbox. I decided the rsync that, because here it was 2 days vs 5 hours > syncing. > > After the rsync I did again the backup on that namespace > > doveadm backup -f -n Archive -F /root/backup-accounts.txt > tcp:mailXX.local:542 > > Then I ran a script counting messages in mailboxes of all users on both > servers and a diff showed that everything was ok. > > I guess if you handle it like this you will not loose a message. ;) > > > > > -Original Message- > From: David Morsberger [mailto:da...@mmpcrofton.com] > Sent: 29 December 2020 20:09 > To: dovecot mailing list > Subject: Initial Replication > > I searched the archives and do not see a question/answer for this. > > Should I perform a set of ordered steps after setting up replication? I > have setup dovecot on both ends with identical config except for the > remote hostname. > > Main concern is the existing server gets replicated to the new server. I > want nothing from new server replicated to the old server. Risking > "Trial and error" and "crossing fingers doesnt work with production > emails > > Specifically: > > Do I need to setup the mail directories for the various virtual users on > the remote? If so, do the directories need to empty? > > Should I initially do a manually one-way synch using doveadm from the > existing server? If so, is there a way of turning off automatic > replication while the manual one runs? > > Anything else? > > T > > David >
