Re: 2.3.11.3 on 32bit platforms
On 13/08/20 9:16 pm, Michael Ströder wrote: On 8/13/20 10:56 AM, Aki Tuomi wrote: On 13/08/2020 11:31 Michael Ströder wrote: I'm trying to update openSUSE package on OBS [1] which builds for various OS versions and hardware platforms. To me it seems that a test fails on 32bit platforms: Excerpt of failed test: [ 576s] test-mech.c:370: Assert(#1) failed: strcmp(test_case->username,username) [ 576s] "testuser" != NULL [ 576s] test-mech.c:380: Assert(#1) failed: request->failed == FALSE [ 576s] auth mech APOP 2/84 .. : FAILED I'm getting the same issue on a CentOS 6 i386 build: test-mech.c:371: Assert(#1) failed: strcmp(test_case->username,username) "testuser" != NULL test-mech.c:380: Assert(#1) failed: request->failed == FALSE auth mech APOP 2/84 .. : FAILED Full log of tests is at https://paste.centos.org/view/33771454 Peter
Re: Tests failing on CentOS 6
On 17/08/20 9:17 pm, Timo Sirainen wrote: Looks like it's a gcc bug. It's not initializing the end_of_lines field in the unit test. Since it's in the unit test only, it's not harmful. Of course, the same gcc bug could be hitting some important places in the code.. but that's not a new issue. Only this unit test is really new and exposing this issue. i wasn't sure if it was the test that was the issue or the code that it was testing which is why I'm reluctant to disable the unit tests unless I have to. The problem goes away with: Thanks for the patch, it does indeed fix the issue at hand. I suppose the other way to deal with this might be to use gcc from devtoolset 9, but I prefer to stick with the CentOS stock GCC if at all possible. Now I'm getting a different failure when building the i386 packages which was already reported by someone else. I will follow up on this one in that thread. Peter
Re: Apple Mail Since upgrade to dovecot 2.3.x unable to connect
On Mon, 17 Aug 2020, Johannes Rohr wrote: You need to set ssl_min_protocol = TLSv1.2 # or TLSv1 Thanks, tried both, but unsuccessfully. Don't give up too easily/early on this. I said this before, but MacOSX Mail behaves weirdly. I've more than once changed a server setting, without apparent effect, only to have MacOSX Mail mysteriously start working again after some time. Maybe it caches settings. Also, disable "Automatic manage connection" as failure to establish a successful session will cause your client to do some auto-wandering to discover settings, which could really do your head in. Joseph Tam
Re: MDBOX DSYNC error: Broken physical size in mailbox
Further to below. I'm getting these errors in the logs: failed: read(/#userdir#/mdbox/storage/m.19) failed: zlib.read(/#userdir#/mdbox/storage/m.19): gz trailer has wrong CRC value at 10376033 (FETCH BODY[]) I'm not sure if it's relevant, but I've set bz2 as the compression method and not gzip... Has anyone any ideas? Thanks! Paul. On 2020-08-17 12:09, paul-dovecotl...@trainor.nz wrote: Hi All, I currently have a small Dovecot server (Server A) and I've installed a second dovecot mailbox server (server B) and am trying to sync mailboxes from Server A to Server B. Both servers sit behind two dovecot directors on separate hosts and have identical config files (doveconf -n output below). Mailboxes on Server A are on an NFS mount. Server A has been working fine with no issues for a couple of years. I'm running this command on Server A: doveadm sync -u #user# tcp:#newservername#:24245 Small mailboxes with few items are syncing OK.. but most mailboxes fail (sycn stops) with the following type of error: (Mailbox name, storage file, UID and sizes vary). dsync-local(#username#): Error: Mailbox INBOX: Cache /#usershomedirectory#/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.cache: Deleting corrupted cache record uid=9: UID 9: Broken physical size in mailbox INBOX: read(/#usershomedirectory#/mdbox/storage/m.1) failed: Cached message size larger than expected (60616 > 8688, box=INBOX, UID=9) If I run it again, I'll get the same error, but with a new UID. If I do a local migration instead of server to server, I still get the errors. e.g. doveadm sync -u #user# maildir:~/Maildir-test/ I tried running a force resync (doveadm force-resync -u #user# -f "*) but it didn't help. There's no issues from an imap client accessing any emails. Using imapsync to sync affected mailboxes works fine for example. But... if I then run a dsync on Server B (doveadm sync -u #user# maildir:~/Maildir-test/) on an account that was successfully migrated with imapsync, I get the issue again. How worried should I be about these corrupted cache records, and any ideas how to resolve? Thanks in advance for your help! Paul. --- output of doveconf -n --- # 2.3.11.3 (502c39af9): /etc/dovecot/dovecot.conf # Pigeonhole version 0.5.11 (6c69c917) # OS: Linux 5.3.0-1032-aws x86_64 Ubuntu 18.04.5 LTS hostname = ### lda_mailbox_autocreate = yes lda_mailbox_autosubscribe = yes login_trusted_networks = ### mail_fsync = always mail_location = mdbox:~/mdbox mail_plugins = " acl notify replication" managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date index ihave duplicate mime foreverypart extracttext mmap_disable = yes namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = separator = / type = private } namespace shared { list = children location = mdbox:/mailhomes/%%d/%%n/mdbox:INDEXPVT=/mailhomes/%d/%n/shared prefix = shared/%%u/ separator = / subscriptions = no type = shared } passdb { args = /etc/dovecot/dovecot-ldap.conf.ext driver = ldap } plugin { acl = vfile:/tmp/global-acls:cache_secs=5 mail_plugins = " acl notify replication" sieve = file:~/sieve;active=~/.dovecot.sieve sieve_before = /mailhomes/sieve/global/SpamToJunk.sieve sieve_max_actions = 32 sieve_max_redirects = 4 sieve_max_script_size = 1M sieve_quota_max_scripts = 20 sieve_quota_max_storage = 10M sieve_redirect_envelope_from = sender zlib_save = bz2 zlib_save_level = 6 } protocols = " imap lmtp sieve submission sieve" recipient_delimiter = - service doveadm { inet_listener { port = 24245 } } service imap-login { process_min_avail = 2 } service imap { process_limit = 4096 } service lmtp { inet_listener lmtp { port = 24 } } service managesieve-login { inet_listener sieve { port = 4190 } process_min_avail = 2 service_count = 1 } service managesieve { process_limit = 1024 } service submission-login { inet_listener submission { port = 587 } } ssl = required ssl_cert =
Re: Apple Mail Since upgrade to dovecot 2.3.x unable to connect
On 17 Aug 2020, at 05:10, Gerald Galster wrote: > I don't know how detailed this is in older Apple Mail versions I don't think the detail has changed in many many years, if at all. I remember using the logs to troubleshoot security issues 15 years ago. Mac OS 10.11 El Capitan was released in 2015, not 2016, but I don't think that makes any difference. El Capitan uses outdate versions of openssl (0.9.9). Sierra (10.12) and High Sierra (10.13) have an updated stack and work fine with TLSv1.2. Because the issue is the unix level tools, this is not generally something you can work around with a third-arty client unless you find one with its own stack. Webmail would be the solution if someone refuses or is unable to update. Any machine that is less than about 10-12 years old can update to 10.13 at no cost though. -- I said pretend you've got no money, she just laughed and said, 'Eh you're so funny.' I said, 'Yeah? Well I can't see anyone else smiling in here.'
Re: Apple Mail Since upgrade to dovecot 2.3.x unable to connect
Am 17.08.20 um 13:10 schrieb Gerald Galster: >>> You need to set >>> >>> ssl_min_protocol = TLSv1.2 # or TLSv1 >> Thanks, tried both, but unsuccessfully. Again, is there any debug >> setting that allows me to see what SSL version was requested? Without >> this, this is fumbling in the dark. > In the german version of Apple Mail go to menu "Fenster" / "Verbindug prüfen". > > There you can check the connection and log all transactions. > > I don't know how detailed this is in older Apple Mail versions, but you could > try. > > READ Aug 17 13:05:32.041 [kCFStreamSocketSecurityLevelTLSv1_2] -- > host:mail.server.com -- port:587 -- socket:0x65ff1980 -- > thread:0x6e5cb340 > 235 2.7.0 Authentication successful Thanks Gerald, I'll try that. Strange though that the info isn't in the dovecot debug log. Cheers, Johannes > > > Best regards > Gerald signature.asc Description: OpenPGP digital signature
Re: Apple Mail Since upgrade to dovecot 2.3.x unable to connect
ssl_cert = This is wrong, it should be: ssl_cert = The address idaweb-mail.rooot.de does not resolve. There is a webmail.rooot.de , but its certificate is for mail.rooot.de , which is wrong. There is also a mail.rooot.de , whose certificate is also for mail.rooot.de , which is okay. Yet another possibility (but it seems less likely given that an Apple Mail from 2016 is a reasonably recent mail client) is that it does not support recent enough SSL protocols, which were enforced by your server upgrade. See the entries for MinProtocol and CipherString in the openssl.cnf file on the server. Gregory
Re: Apple Mail Since upgrade to dovecot 2.3.x unable to connect
>> You need to set >> >> ssl_min_protocol = TLSv1.2 # or TLSv1 > > Thanks, tried both, but unsuccessfully. Again, is there any debug > setting that allows me to see what SSL version was requested? Without > this, this is fumbling in the dark. In the german version of Apple Mail go to menu "Fenster" / "Verbindug prüfen". There you can check the connection and log all transactions. I don't know how detailed this is in older Apple Mail versions, but you could try. READ Aug 17 13:05:32.041 [kCFStreamSocketSecurityLevelTLSv1_2] -- host:mail.server.com -- port:587 -- socket:0x65ff1980 -- thread:0x6e5cb340 235 2.7.0 Authentication successful Best regards Gerald
Re: Apple Mail Since upgrade to dovecot 2.3.x unable to connect
Am 17.08.20 um 12:16 schrieb Aki Tuomi: > You need to set > > ssl_min_protocol = TLSv1.2 # or TLSv1 Thanks, tried both, but unsuccessfully. Again, is there any debug setting that allows me to see what SSL version was requested? Without this, this is fumbling in the dark. Cheers, Johannes signature.asc Description: OpenPGP digital signature
Re: Apple Mail Since upgrade to dovecot 2.3.x unable to connect
> On 17/08/2020 12:51 Johannes Rohr wrote: > > > |Dear all,| > > |a couple of days ago I upgraded our server from Ubuntu 18.04 to 20.04, > thereby upgrading dovecot from 2.2.x to 2.3.x. > | > > |Since then, some older versions of apple's mail.app (bundled with el > Capitano, released in 2016) no longer connect. When I turn on SSL > debugging, I see:| > > |Debug: SSL error: SSL_accept() failed: error:14209102:SSL > routines:tls_early_post_process_client_hello:unsupported protocol > imap-login: Debug: SSL error: SSL_accept() syscall failed: Invalid argument| > > || > > |Unfortunately, it doesn't reveal the name of the unsupported protocol. > Also, what about the failed syscall? Does dovecot try and fail to open > some file?| > > |Here are the contents of /etc/dovecot/conf.d/10-ssl.conf:| > > | ssl = yes > ssl_cert = ssl_key = ssl_ca = ssl_client_ca_dir = /etc/ssl/certs > ssl_dh = | > > |I would greatly appreciate any hints! > | > > |Cheers,| > > |Johannes > | > > | > | > > || You need to set ssl_min_protocol = TLSv1.2 # or TLSv1 Aki
Apple Mail Since upgrade to dovecot 2.3.x unable to connect
|Dear all,| |a couple of days ago I upgraded our server from Ubuntu 18.04 to 20.04, thereby upgrading dovecot from 2.2.x to 2.3.x. | |Since then, some older versions of apple's mail.app (bundled with el Capitano, released in 2016) no longer connect. When I turn on SSL debugging, I see:| |Debug: SSL error: SSL_accept() failed: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol imap-login: Debug: SSL error: SSL_accept() syscall failed: Invalid argument| || |Unfortunately, it doesn't reveal the name of the unsupported protocol. Also, what about the failed syscall? Does dovecot try and fail to open some file?| |Here are the contents of /etc/dovecot/conf.d/10-ssl.conf:| | ssl = yes ssl_cert =
Apple Mail Since upgrade to dovecot 2.3.x unable to connect
|Dear all,| |a couple of days ago I upgraded our server from Ubuntu 18.04 to 20.04, thereby upgrading dovecot from 2.2.x to 2.3.x. | |Since then, some older versions of apple's mail.app (bundled with el Capitano, released in 2016) no longer connect. When I turn on SSL debugging, I see:| |Debug: SSL error: SSL_accept() failed: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol imap-login: Debug: SSL error: SSL_accept() syscall failed: Invalid argument| || |Unfortunately, it doesn't reveal the name of the unsupported protocol. Also, what about the failed syscall? Does dovecot try and fail to open some file?| |Here are the contents of /etc/dovecot/conf.d/10-ssl.conf:| | ssl = yes ssl_cert = signature.asc Description: OpenPGP digital signature
Re: Tests failing on CentOS 6
On 15. Aug 2020, at 14.18, Peter wrote: > > Getting this when attempting to build 2.3.11.3 on CentOS 6: > > test-mail-cache.c:176: Assert failed: > strcmp(str_c(str),"123\nfoo\n456\nbar\n") >"" != "123 > foo > 456 > bar > " > test-mail-cache.c:176: Assert failed: > strcmp(str_c(str),"123\nfoo\n456\nbar\n") >"" != "123 > foo > 456 > bar > " > mail cache uncommitted lookups ... : > FAILED > > Full make check output is at https://paste.centos.org/view/b48d38a9 > > I can provide full build logs if you want, but that's a 4M file so I'll > provide it upon request. > > For now I'm going ot have to bypass the make check stage of the build for > CentOS 6, but I worry that the failed check could be indicative of something > critical. Looks like it's a gcc bug. It's not initializing the end_of_lines field in the unit test. Since it's in the unit test only, it's not harmful. Of course, the same gcc bug could be hitting some important places in the code.. but that's not a new issue. Only this unit test is really new and exposing this issue. The problem goes away with: diff --git a/src/lib-index/test-mail-cache.c b/src/lib-index/test-mail-cache.c index e4e5503f6..4734904e8 100644 --- a/src/lib-index/test-mail-cache.c +++ b/src/lib-index/test-mail-cache.c @@ -130,11 +130,13 @@ static void test_mail_cache_fields(void) struct test_header_data header_data1 = { .line1 = 15, .line2 = 30, + .end_of_lines = 0, .headers = "foo\nbar\n", }; struct test_header_data header_data2 = { .line1 = 10, .line2 = 20, + .end_of_lines = 0, .headers = "123\n456\n", }; mail_cache_add(cache_trans, 1, cache_fields[TEST_FIELD_HEADER1].idx,