Upgrade path
Hello, I have a configuration with two proxy/director and two backend with replication. All at version 2.3.10.1. What is the suggested upgrade path to 2.3.15? I think to switch traffic to only one proxy and one backend and upgrade the two servers that remain without traffic. Then I switch the traffic to these upgraded servers and proceed with the upgrade of the others two. Is this correct? Or is best to upgrade first the two proxy/director and next the two backend? Thanks, Andrea -- __ Business is like riding a bicycle. Either you keep moving or you fall down. __ TIM San Marino S.p.A. Andrea Gabellini Engineering R&D TIM San Marino S.p.A. - https://www.telecomitalia.sm Via Ventotto Luglio, 212 - Piano -2 47893 - Borgo Maggiore - Republic of San Marino Tel: (+378) 0549 886237 Fax: (+378) 0549 886188 -- Informativa Privacy Questa email ha per destinatari dei contatti presenti negli archivi di TIM San Marino S.p.A.. Tutte le informazioni vengono trattate e tutelate nel rispetto della normativa vigente sulla protezione dei dati personali (Reg. EU 2016/679). Per richiedere informazioni e/o variazioni e/o la cancellazione dei vostri dati presenti nei nostri archivi potete inviare una email a priv...@telecomitalia.sm. Avviso di Riservatezza Il contenuto di questa e-mail e degli eventuali allegati e' strettamente confidenziale e destinato alla/e persona/e a cui e' indirizzato. Se avete ricevuto per errore questa e-mail, vi preghiamo di segnalarcelo immediatamente e di cancellarla dal vostro computer. E' fatto divieto di copiare e divulgare il contenuto di questa e-mail. Ogni utilizzo abusivo delle informazioni qui contenute da parte di persone terze o comunque non indicate nella presente e-mail potra' essere perseguito ai sensi di legge.
Re: CVE-2021-33515: SMTP Submission service STARTTLS injection
On Mon, 21 Jun 2021 13:51:30 +0200
Timo Sirainen wrote:
> Open-Xchange Security Advisory 2021-06-21
>
> Product: Dovecot
> Vendor: OX Software GmbH
> Internal reference: DOV-4583 (Bug ID)
> Vulnerability type: CWE-74: Failure to Sanitize Data into a Different
> Plane ('Injection') Vulnerable version: 2.3.0-2.3.14
> Vulnerable component: submission
> Report confidence: Confirmed
> Solution status: Fixed by Vendor
> Fixed version: 2.3.14.1
> Vendor notification: 2021-05-21
> Solution date: 2021-05-22
> Public disclosure: 2021-06-21
> CVE reference: CVE-2021-33515
> CVSS: 4.2 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N)
> Researcher credit: Fabian Ising and Damian Poddebniak of Münster
> University of Applied Sciences
>
> Vulnerability Details:
>
> On-path attacker could inject plaintext commands before STARTTLS
> negotiation that would be executed after STARTTLS finished with the
> client. Only the SMTP submission service is affected.
>
> Risk:
>
> Attacker can potentially steal user credentials and mails. The
> attacker needs to have sending permissions on the submission server
> (a valid username and password).
>
> Workaround:
>
> None.
>
> Solution:
>
> Operators should update to 2.3.14.1 or later version.
>
Centos 7 has no repo with 2.3.15. I am using 2.2.36 (1f10bfa63). Is
this OK?
This is my personal server, hence all the accounts are mine, so it
isn't like I am going to hack myself.
Re: CVE-2021-33515: SMTP Submission service STARTTLS injection
> Am 22.06.2021 um 11:11 schrieb li...@lazygranch.com:
>
>
>
> On Mon, 21 Jun 2021 13:51:30 +0200
> Timo Sirainen wrote:
>
>> Open-Xchange Security Advisory 2021-06-21
>>
>> Product: Dovecot
>> Vendor: OX Software GmbH
>> Internal reference: DOV-4583 (Bug ID)
>> Vulnerability type: CWE-74: Failure to Sanitize Data into a Different
>> Plane ('Injection') Vulnerable version: 2.3.0-2.3.14
>> Vulnerable component: submission
>> Report confidence: Confirmed
>> Solution status: Fixed by Vendor
>> Fixed version: 2.3.14.1
>> Vendor notification: 2021-05-21
>> Solution date: 2021-05-22
>> Public disclosure: 2021-06-21
>> CVE reference: CVE-2021-33515
>> CVSS: 4.2 (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N)
>> Researcher credit: Fabian Ising and Damian Poddebniak of Münster
>> University of Applied Sciences
>>
>> Vulnerability Details:
>>
>> On-path attacker could inject plaintext commands before STARTTLS
>> negotiation that would be executed after STARTTLS finished with the
>> client. Only the SMTP submission service is affected.
>>
>> Risk:
>>
>> Attacker can potentially steal user credentials and mails. The
>> attacker needs to have sending permissions on the submission server
>> (a valid username and password).
>>
>> Workaround:
>>
>> None.
>>
>> Solution:
>>
>> Operators should update to 2.3.14.1 or later version.
>>
>
> Centos 7 has no repo with 2.3.15. I am using 2.2.36 (1f10bfa63). Is
> this OK?
>
check https://repo.dovecot.org
/Götz
smime.p7s
Description: S/MIME cryptographic signature
Dovecot deliver and imap process hangs
Hello. Dovecot version: 2.2.36 OS: CentOS Linux release 7.9.2009 (Core) Kernel: 3.10.0-1160.11.1.el7.x86_64 I have two dovecot servers in replication master/master. Sometimes happens that deliver or imap process hangs and causing high CPU usage. In log's I only see locking failures but not initial cause why this happened. For mail storage I use ZFS pool with compression enabled. I made some digging and find this option: mmap_disable = yes. I will try this setting today evening. But I wondering if you have any idea why this happening and how to start solving this problems? Is there any additional setting like mmap_disable that can help solved this issues? -- BR
Re: CVE-2021-33515: SMTP Submission service STARTTLS injection
On 22. Jun 2021, at 11.11, li...@lazygranch.com wrote: > >> Vulnerability Details: >> >> On-path attacker could inject plaintext commands before STARTTLS >> negotiation that would be executed after STARTTLS finished with the >> client. Only the SMTP submission service is affected. > > Centos 7 has no repo with 2.3.15. I am using 2.2.36 (1f10bfa63). Is > this OK? > > This is my personal server, hence all the accounts are mine, so it > isn't like I am going to hack myself. Only the submission service is vulnerable, and v2.2.36 doesn't have the submission service at all. So it's not vulnerable to this. And for the Sieve excessive resource usage it's not really a problem especially with personals servers.
Re: libdict_lua linking issues
On 21. Jun 2021, at 18.57, James wrote: > > On 21/06/2021 17:39, Daniel J. Luke wrote: >> On Jun 21, 2021, at 7:20 AM, Timo Sirainen wrote: >>> Here's a new release with some security fixes and quite a lot of other >>> changes as well. >>> >>> * Removed support for Lua 5.2. Use version 5.1 or 5.3 instead. >> Looks like it doesn't want to build w/o lua now. >> >> On my MacOS system configure says: > > And on OmniOS / Solaris it failed with: > > libtool: link: gcc -std=gnu99 -m64 -march=x86-64 -fPIC -Os -Wall -W > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts > -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -m64 > -o test-dict test-dict.o ./.libs/libdict.a ../lib-test/.libs/libtest.a > ../lib/.libs/liblib.a -lsocket -lnsl -lsendfile > gcc: error: ./.libs/libdict_lua.a: No such file or directory > gmake[3]: *** [Makefile:630: test-dict-client] Error 1 Attached patch should work? You'll need to run autogen.sh again. lib-dict-lua-link.patch Description: Binary data
ssl_min_protocol v2.3.15
Hello, it seems that the default value for ssl_min_protocol has changed from TLSv1 to TLSv1.2, right? After upgrading to v2.3.15 and with ssl_min_protocol commented out, the server no longer offers TLSv1 and TLSv1.1. This is a good idea, but should be documented. Theo
Re: libdict_lua linking issues
On 22/06/2021 12:30, Timo Sirainen wrote: And on OmniOS / Solaris it failed with: libtool: link: gcc -std=gnu99 -m64 -march=x86-64 -fPIC -Os -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -m64 -o test-dict test-dict.o ./.libs/libdict.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -lsocket -lnsl -lsendfile gcc: error: ./.libs/libdict_lua.a: No such file or directory gmake[3]: *** [Makefile:630: test-dict-client] Error 1 Attached patch should work? You'll need to run autogen.sh again. No, similar error, I am slowly investigating. I didn't run autogen.sh in the first place so I can't run it again. Running for the first time it moans about missing libtool: Warning: libtoolize does not appear to be available. This means that the automatic build preparation via autoreconf will probably not work. Preparing the build by running each step individually, however, should work and will be done automatically for you if autoreconf fails. ERROR: Unable to locate GNU Libtool. ERROR: To prepare the Dovecot build system from scratch, at least version 1.4.2 of GNU Libtool must be installed.
Re: libdict_lua linking issues
On Tue, Jun 22, 2021 at 01:30:49PM +0200, Timo Sirainen wrote: > > And on OmniOS / Solaris it failed with: > > > > libtool: link: gcc -std=gnu99 -m64 -march=x86-64 -fPIC -Os -Wall -W > > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith > > -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime > > -Wstrict-aliasing=2 -m64 -o test-dict test-dict.o ./.libs/libdict.a > > ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -lsocket -lnsl -lsendfile > > gcc: error: ./.libs/libdict_lua.a: No such file or directory > > gmake[3]: *** [Makefile:630: test-dict-client] Error 1 > > Attached patch should work? You'll need to run autogen.sh again. This works for me on MacOS both with and without lua (ran autoconf -fi since autogen.sh isn't in the source tarball). Thanks! -- Daniel J. Luke
Re: libdict_lua linking issues
On 22/06/2021 12:30, Timo Sirainen wrote: libtool: link: gcc -std=gnu99 -m64 -march=x86-64 -fPIC -Os -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -m64 -o test-dict test-dict.o ./.libs/libdict.a ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -lsocket -lnsl -lsendfile gcc: error: ./.libs/libdict_lua.a: No such file or directory gmake[3]: *** [Makefile:630: test-dict-client] Error 1 Attached patch should work? You'll need to run autogen.sh again. Patching src/lib-dict/Makefile.in did the job. I don't know what is wrong with autoconf and automake - obviously I need a suite of tools to enable portability of autoconf, automake and libtool.
Re: Dovecot v2.3.15 released
Il 21/06/21 13:18, Timo Sirainen ha scritto:
+ imap: Support official RFC8970 preview/snippet syntax. Old methods of
retrieving preview information via IMAP commands ("SNIPPET and PREVIEW
with explicit algorithm selection") have been deprecated.
Hi,
After upgrading dovecot from 2.3.14 to 2.3.15 I noticed a problem
parsing FETCH response of PREVIEW attribute.
Basically there is any space after the preview content and the rest of
the string which causes issues on parsing:
a UID FETCH 2539 (MODSEQ UID FLAGS INTERNALDATE PREVIEW
BODY.PEEK[HEADER.FIELDS (FROM TO SUBJECT DATE)])
* 8 FETCH (UID 2539 MODSEQ (3) FLAGS (\Seen $HasNoAttachment)
INTERNALDATE "04-Mar-2021 12:18:02 +0100" PREVIEW
"test"BODY[HEADER.FIELDS (FROM TO SUBJECT DATE)] {151}
With dovecot 2.3.14 there was no problem:
a UID FETCH 2539 (MODSEQ UID FLAGS INTERNALDATE PREVIEW
BODY.PEEK[HEADER.FIELDS (FROM TO SUBJECT DATE)])
* 8 FETCH (UID 2539 MODSEQ (3) FLAGS (\Seen $HasNoAttachment)
INTERNALDATE "04-Mar-2021 12:18:02 +0100" PREVIEW (FUZZY "test")
BODY[HEADER.FIELDS (FROM TO SUBJECT DATE)] {151}
Can you check it please?
Thanks
--
Alessio Cecchi
Postmaster @ http://www.qboxmail.it
https://www.linkedin.com/in/alessice
2.3.15 Dockerfile
I'm having hard-to-debug issues compiling 2.3.15 using Alpine; for some reasons I'd like to repeat that using buster. Where did you publish the Dockerfile for the 'official' repository?
