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
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,
