Re: deliverability test

[Aki Tuomi via dovecot]

> On 11/03/2024 13:43 EET Aki Tuomi  wrote:
> 
>  
> Test
> 
> Aki

Apologies to everyone, this mail was not supposed to make it to the list, yet 
it did.

In that tune, due to a bug in mailman, some of the recent mails have failed to 
make it to the list, so if you have sent a mail after 3rd of March (last  seen 
mail in the archive), you may want to send it again.

I'll be reporting this to the mailman3 developers.

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

deliverability test

[Aki Tuomi]

Test

Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: How to get a server listed in the IMAP Test wiki?

[justina colmena ~biz]

On February 24, 2023 10:19:54 AM EST, Timo Sirainen  wrote:
> If you want, you can post them publicly here in case someone else wants to 
> verify.

Who are you doxxing? What other crimes are you confessing to publicly?

-- 
https://justina.abeja.colmena.biz/

Re: How to get a server listed in the IMAP Test wiki?

[Timo Sirainen]

On 24. Feb 2023, at 9.29, Leander Beernaert  wrote:
> 
> 
> Hey Timo,
> 
> Thanks for the quick turnaround, once we have the test results I'll contact 
> you again. 

OK.

> Should I also include instructions on how to run the a self contained server 
> with a dummy backend so you can independently verify our results?

Too much effort for me, I trust the results are good :) If you want, you can 
post them publicly here in case someone else wants to verify.

Re: How to get a server listed in the IMAP Test wiki?

[Aki Tuomi]

Justina, can you please stop spamming the list with irrelevant messages? 

Aki

> On 24/02/2023 12:24 EET justina colmena ~biz  wrote:
> 
> 
> Something I can't quite place finger on here. Altogether too much Mafia, in 
> the bulk email business generally, and I know Switzerland borders on Italy ...
> 
> This sounds, (albeit vaguely,) altogether too much like the thieves I seem to 
> have fallen amongst lately. Two stolen trucks, three stolen laptops, another 
> one wrecked, three or four stolen cell phones, passwords GPG keys, city hall 
> hookers and towers and parking masters took everything the first moment I 
> turned my back on it. Smashed the windows, hot wired the ignition at 4am 
> assaulted me, mugged me in the street after I made a police complaint. I 
> barely made it away alive. Another cop trying to arrest me without a warrant 
> as I hopped a plane took a flight away from the city hall lynch mob. And the 
> corrupt corporate-paid cops who previously stole my car, cell phone, digital 
> camera, photos and laptop in another state, too.
> 
> And that's only the latest such violent attack. In real life. People plannimg 
> crimes and getting away with crimes in real life. Bragging about it online is 
> always what what gets them caught in the end.
> 
> And so far the thieves and robbers and assailants are apparently not being 
> prosecuted at all for the violent crimes they are committing but they were 
> forced to let me go since there were no charges they could file against the 
> victim of their horrible crimes and atrocities under color of law. And City 
> Hall is still in the bedroom & bathroom business to boot.
> 
> 
> On February 24, 2023 2:29:41 AM EST, Leander Beernaert 
>  wrote:
> > 
> > Hey Timo,
> > 
> > Thanks for the quick turnaround, once we have the test results I'll contact 
> > you again. 
> > 
> > Should I also include instructions on how to run the a self contained 
> > server with a dummy backend so you can independently verify our results?
> > 
> > Leander Beernaert
> > Proton AG
> > 
> > --- Original Message ---
> >  On Thursday, February 23rd, 2023 at 8:59 PM, Timo Sirainen 
> >  wrote:
> > 
> > 
> > > On 23. Feb 2023, at 16.13, Leander Beernaert 
> > >  wrote:
> > > 
> > > > 
> > > > 
> > > > Hey,
> > > > 
> > > > We recently announced Gluon (https://github.com/ProtonMail/gluon/) our 
> > > > IMAP server library we are using in Proton 
> > > > Bridge(https://github.com/ProtonMail/proton-bridge). We would love to 
> > > > have it have it listed in the IMAP Server Compliancy Status wiki page 
> > > > (https://imapwiki.org/ImapTest/ServerStatus). What do we need to do or 
> > > > whom do we need to contact to make this happen?
> > > 
> > > There was so much spam that we disabled all outside access to the wiki. 
> > > Maybe we should move it to github/sphinx similarly to doc.dovecot.org 
> > > (http://doc.dovecot.org) so we could get pull requests instead. For now 
> > > just email me what you want there and I can add it.
> > > 
> > > 
> > > > Additionally, We have been using running imaptest 
> > > > (https://github.com/dovecot/imaptest) against our server library, but 
> > > > due to variety of configuration parameters, we would really appreciate 
> > > > it (if possible) if someone could point out to us the test setup used 
> > > > to validate each of those servers.
> > > 
> > > 
> > > I updated the page to specify how the different columns can be tested. 
> > > It's the same for all servers.
> > > 
> > 
> > 
> -- 
> https://justina.abeja.colmena.biz/

Re: How to get a server listed in the IMAP Test wiki?

[justina colmena ~biz]

Something I can't quite place finger on here. Altogether too much Mafia, in the 
bulk email business generally, and I know Switzerland borders on Italy ...

This sounds, (albeit vaguely,) altogether too much like the thieves I seem to 
have fallen amongst lately. Two stolen trucks, three stolen laptops, another 
one wrecked, three or four stolen cell phones, passwords GPG keys, city hall 
hookers and towers and parking masters took everything the first moment I 
turned my back on it. Smashed the windows, hot wired the ignition at 4am 
assaulted me, mugged me in the street after I made a police complaint. I barely 
made it away alive. Another cop trying to arrest me without a warrant as I 
hopped a plane took a flight away from the city hall lynch mob. And the corrupt 
corporate-paid cops who previously stole my car, cell phone, digital camera, 
photos and laptop in another state, too.

And that's only the latest such violent attack. In real life. People plannimg 
crimes and getting away with crimes in real life. Bragging about it online is 
always what what gets them caught in the end.

And so far the thieves and robbers and assailants are apparently not being 
prosecuted at all for the violent crimes they are committing but they were 
forced to let me go since there were no charges they could file against the 
victim of their horrible crimes and atrocities under color of law. And City 
Hall is still in the bedroom & bathroom business to boot.

On February 24, 2023 2:29:41 AM EST, Leander Beernaert 
 wrote:
>Hey Timo,
>
>Thanks for the quick turnaround, once we have the test results I'll contact 
>you again.
>
>Should I also include instructions on how to run the a self contained server 
>with a dummy backend so you can independently verify our results?
>
>Leander Beernaert
>Proton AG
>
>--- Original Message ---
>On Thursday, February 23rd, 2023 at 8:59 PM, Timo Sirainen  
>wrote:
>
>> On 23. Feb 2023, at 16.13, Leander Beernaert  
>> wrote:
>>
>>> Hey,
>>>
>>> We recently announced Gluon (https://github.com/ProtonMail/gluon/) our IMAP 
>>> server library we are using in Proton 
>>> Bridge(https://github.com/ProtonMail/proton-bridge). We would love to have 
>>> it have it listed in the IMAP Server Compliancy Status wiki page 
>>> (https://imapwiki.org/ImapTest/ServerStatus). What do we need to do or whom 
>>> do we need to contact to make this happen?
>>
>> There was so much spam that we disabled all outside access to the wiki. 
>> Maybe we should move it to github/sphinx similarly to doc.dovecot.org so we 
>> could get pull requests instead. For now just email me what you want there 
>> and I can add it.
>>
>>> Additionally, We have been using running imaptest 
>>> (https://github.com/dovecot/imaptest) against our server library, but due 
>>> to variety of configuration parameters, we would really appreciate it (if 
>>> possible) if someone could point out to us the test setup used to validate 
>>> each of those servers.
>>
>> I updated the page to specify how the different columns can be tested. It's 
>> the same for all servers.
-- 
https://justina.abeja.colmena.biz/

Re: How to get a server listed in the IMAP Test wiki?

[Leander Beernaert]

Hey Timo,

Thanks for the quick turnaround, once we have the test results I'll contact you 
again.

Should I also include instructions on how to run the a self contained server 
with a dummy backend so you can independently verify our results?

Leander Beernaert
Proton AG

--- Original Message ---
On Thursday, February 23rd, 2023 at 8:59 PM, Timo Sirainen  
wrote:

> On 23. Feb 2023, at 16.13, Leander Beernaert  
> wrote:
>
>> Hey,
>>
>> We recently announced Gluon (https://github.com/ProtonMail/gluon/) our IMAP 
>> server library we are using in Proton 
>> Bridge(https://github.com/ProtonMail/proton-bridge). We would love to have 
>> it have it listed in the IMAP Server Compliancy Status wiki page 
>> (https://imapwiki.org/ImapTest/ServerStatus). What do we need to do or whom 
>> do we need to contact to make this happen?
>
> There was so much spam that we disabled all outside access to the wiki. Maybe 
> we should move it to github/sphinx similarly to doc.dovecot.org so we could 
> get pull requests instead. For now just email me what you want there and I 
> can add it.
>
>> Additionally, We have been using running imaptest 
>> (https://github.com/dovecot/imaptest) against our server library, but due to 
>> variety of configuration parameters, we would really appreciate it (if 
>> possible) if someone could point out to us the test setup used to validate 
>> each of those servers.
>
> I updated the page to specify how the different columns can be tested. It's 
> the same for all servers.

Re: How to get a server listed in the IMAP Test wiki?

[Timo Sirainen]

On 23. Feb 2023, at 16.13, Leander Beernaert  
wrote:
> 
> Hey,
> 
> We recently announced Gluon (https://github.com/ProtonMail/gluon/) our IMAP 
> server library we are using in Proton 
> Bridge(https://github.com/ProtonMail/proton-bridge). We would love to have it 
> have it listed in the IMAP Server Compliancy Status wiki page 
> (https://imapwiki.org/ImapTest/ServerStatus). What do we need to do or whom 
> do we need to contact to make this happen?

There was so much spam that we disabled all outside access to the wiki. Maybe 
we should move it to github/sphinx similarly to doc.dovecot.org 
<http://doc.dovecot.org/> so we could get pull requests instead. For now just 
email me what you want there and I can add it.

> Additionally, We have been using running imaptest 
> (https://github.com/dovecot/imaptest) against our server library, but due to 
> variety of configuration parameters, we would really appreciate it (if 
> possible) if someone could point out to us the test setup used to validate 
> each of those servers.

I updated the page to specify how the different columns can be tested. It's the 
same for all servers.

How to get a server listed in the IMAP Test wiki?

[Leander Beernaert]

Hey,

We recently announced Gluon (https://github.com/ProtonMail/gluon/) our IMAP 
server library we are using in Proton 
Bridge(https://github.com/ProtonMail/proton-bridge). We would love to have it 
have it listed in the IMAP Server Compliancy Status wiki page 
(https://imapwiki.org/ImapTest/ServerStatus). What do we need to do or whom do 
we need to contact to make this happen?

Additionally, We have been using running imaptest 
(https://github.com/dovecot/imaptest) against our server library, but due to 
variety of configuration parameters, we would really appreciate it (if 
possible) if someone could point out to us the test setup used to validate each 
of those servers.

Thank you in advance for your time.

Kind Regards,
Leander Beernaert
Proton AG

test sieve plugin(?) development

[Marc]

Say for testing purposes I would like to add sender email addresses to a 
database file (eg gdbm) per user. How would I go about doing this?


Do I need to create something like in 
https://github.com/dovecot/pigeonhole/tree/src/lib-sieve/plugins

Or can I just create a go binary, and parse data to it? Is there not something 
like a hello world example for this?

Re: test-crypto.c - Assert failed

[Michael Slusarz]

> On 07/27/2022 12:50 AM MDT Tamsy  wrote:
> 
> On a new standard Ubuntu 22.04 LTS installation Dovecot's "configure &&
> make" runs through but "make check" fails.
> 
> Is dovecot-2.3.19.1 not yet compatible with openSSL 3.0.2 (openssl
> 3.0.2-0ubuntu1.6) or is this just happening here?

As has been discussed on this list previously, Dovecot 2.3.x is not (yet) fully 
compatible with openSSL 3.

michael

Re: test-crypto.c - Assert failed

[Tamsy]

 Original Message 
From: Tamsy [mailto:dovecot-l...@mohtex.net]
Sent: Wednesday, July 27, 2022 at 11:31
To: Dovecot
Subject: test-crypto.c - Assert failed

Dear List,

Please pardon me if this has been already discussed before. I couldn't
find the matter with a quick search.

On a new standard Ubuntu 22.04 LTS installation Dovecot's "configure &&
make" runs through but "make check" fails.

Is dovecot-2.3.19.1 not yet compatible with openSSL 3.0.2 (openssl
3.0.2-0ubuntu1.6) or is this just happening here?


Distributor ID: Ubuntu
Description:    Ubuntu 22.04 LTS
Release:    22.04
Codename:   jammy

Linux 5.15.0-41-generic #44-Ubuntu SMP Wed Jun 22 14:20:53 UTC 2022
x86_64 x86_64 x86_64 GNU/Linux


$ make check


test_cipher_test_vectors . : ok
test_cipher_aead_test_vectors  : ok
test_hmac_test_vectors ... : ok
test_load_v1_keys  : ok
test_load_v1_key . : ok
test_load_v1_public_key .. : ok
test_load_v2_key . : ok
test_load_v2_public_key .. : ok
test_get_info_v2_key . : ok
test_gen_and_get_info_rsa_pem  : ok
test_get_info_rsa_private_key  : ok
test_get_info_invalid_keys ... : ok
test_get_info_key_encrypted .. : ok
test_get_info_pw_encrypted ... : ok
test-crypto.c:827: Assert failed: ret == TRUE
Panic: file dcrypt-openssl.c: line 2639
(dcrypt_openssl_private_to_public_key): assertion failed: (priv_key !=
NULL && pub_key_r != NULL)
Error: Raw backtrace: ./test-crypto(+0x60704) [0x168704] ->
./test-crypto(backtrace_append+0x1c) [0x168893] ->
./test-crypto(backtrace_get+0x2a) [0x1688bf] -> ./test-crypto(+0x28ef4)
[0x130ef4] -> ./test-crypto(default_fatal_handler+0) [0x130fc6] ->
./test-crypto(default_error_handler+0) [0x131014] ->
./test-crypto(i_fatal+0) [0x1312ae] ->
.libs/libdcrypt_openssl.so(+0xe795) [0x4ea3795] ->
./test-crypto(dcrypt_key_convert_private_to_public+0x7b) [0x11eeb1] ->
./test-crypto(+0x21655) [0x129655] -> ./test-crypto(+0x23d66) [0x12bd66]
-> ./test-crypto(test_run+0x21) [0x12c13a] -> ./test-crypto(main+0x83)
[0x12af16] -> /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x4893d90] ->
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x4893e40] ->
./test-crypto(_start+0x25) [0x11c1a5]
../../run-test.sh: line 39: 164971 Aborted (core dumped)
/usr/bin/valgrind -q $trace_children --error-exitcode=213
--leak-check=full --gen-suppressions=all --suppressions="$supp_path"
--log-file=$test_out $noundef $*
==164971== Conditional jump or move depends on uninitialised value(s)
==164971==    at 0x514E234: ??? (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==164971==    by 0x514E511: ??? (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==164971==    by 0x504F0F4: EVP_DecryptFinal_ex (in
/usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==164971==    by 0x4E9CD3F: dcrypt_openssl_ctx_sym_final (in
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/.libs/libdcrypt_openssl.so)
==164971==    by 0x11E3DB: dcrypt_ctx_sym_final (in
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==    by 0x1270DE: test_cipher_aead_test_vectors (in
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==    by 0x12BD65: test_run_funcs (in
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==    by 0x12C139: test_run (in
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==    by 0x12AF15: main (in
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==
{
    
    Memcheck:Cond
    obj:/usr/lib/x86_64-linux-gnu/libcrypto.so.3
    obj:/usr/lib/x86_64-linux-gnu/libcrypto.so.3
    fun:EVP_DecryptFinal_ex
    fun:dcrypt_openssl_ctx_sym_final
    fun:dcrypt_ctx_sym_final
    fun:test_cipher_aead_test_vectors
    fun:test_run_funcs
    fun:test_run
    fun:main
}
==164971== 2,304 bytes in 1 blocks are possibly lost in loss record 911
of 947
==164971==    at 0x4848899: malloc (in
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==164971==    by 0x4005D97: malloc (rtld-malloc.h:56)
==164971==    by 0x4005D97: _dlfo_mappings_segment_allocate
(dl-find_object.c:217)
==164971==    by 0x4005D97: _dl_find_object_update_1 (dl-find_object.c:671)
==164971==    by 0x4005D97: _dl_find_object_update (dl-find_object.c:804)
==164971==    by 0x400ECCF: dl_open_worker_begin (dl-open.c:735)
==164971==    by 0x49DEC27: _dl_catch_exception (d

test-crypto.c - Assert failed

[Tamsy]

Dear List,

Please pardon me if this has been already discussed before. I couldn't 
find the matter with a quick search.


On a new standard Ubuntu 22.04 LTS installation Dovecot's "configure && 
make" runs through but "make check" fails.


Is dovecot-2.3.19.1 not yet compatible with openSSL 3.0.2 (openssl 
3.0.2-0ubuntu1.6) or is this just happening here?



Distributor ID: Ubuntu
Description:Ubuntu 22.04 LTS
Release:22.04
Codename:   jammy

Linux 5.15.0-41-generic #44-Ubuntu SMP Wed Jun 22 14:20:53 UTC 2022 
x86_64 x86_64 x86_64 GNU/Linux



$ make check


test_cipher_test_vectors . : ok
test_cipher_aead_test_vectors  : ok
test_hmac_test_vectors ... : ok
test_load_v1_keys  : ok
test_load_v1_key . : ok
test_load_v1_public_key .. : ok
test_load_v2_key . : ok
test_load_v2_public_key .. : ok
test_get_info_v2_key . : ok
test_gen_and_get_info_rsa_pem  : ok
test_get_info_rsa_private_key  : ok
test_get_info_invalid_keys ... : ok
test_get_info_key_encrypted .. : ok
test_get_info_pw_encrypted ... : ok
test-crypto.c:827: Assert failed: ret == TRUE
Panic: file dcrypt-openssl.c: line 2639 
(dcrypt_openssl_private_to_public_key): assertion failed: (priv_key != 
NULL && pub_key_r != NULL)
Error: Raw backtrace: ./test-crypto(+0x60704) [0x168704] -> 
./test-crypto(backtrace_append+0x1c) [0x168893] -> 
./test-crypto(backtrace_get+0x2a) [0x1688bf] -> ./test-crypto(+0x28ef4) 
[0x130ef4] -> ./test-crypto(default_fatal_handler+0) [0x130fc6] -> 
./test-crypto(default_error_handler+0) [0x131014] -> 
./test-crypto(i_fatal+0) [0x1312ae] -> 
.libs/libdcrypt_openssl.so(+0xe795) [0x4ea3795] -> 
./test-crypto(dcrypt_key_convert_private_to_public+0x7b) [0x11eeb1] -> 
./test-crypto(+0x21655) [0x129655] -> ./test-crypto(+0x23d66) [0x12bd66] 
-> ./test-crypto(test_run+0x21) [0x12c13a] -> ./test-crypto(main+0x83) 
[0x12af16] -> /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x4893d90] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x4893e40] -> 
./test-crypto(_start+0x25) [0x11c1a5]
../../run-test.sh: line 39: 164971 Aborted (core dumped) 
/usr/bin/valgrind -q $trace_children --error-exitcode=213 
--leak-check=full --gen-suppressions=all --suppressions="$supp_path" 
--log-file=$test_out $noundef $*

==164971== Conditional jump or move depends on uninitialised value(s)
==164971==at 0x514E234: ??? (in 
/usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==164971==by 0x514E511: ??? (in 
/usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==164971==by 0x504F0F4: EVP_DecryptFinal_ex (in 
/usr/lib/x86_64-linux-gnu/libcrypto.so.3)
==164971==by 0x4E9CD3F: dcrypt_openssl_ctx_sym_final (in 
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/.libs/libdcrypt_openssl.so)
==164971==    by 0x11E3DB: dcrypt_ctx_sym_final (in 
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==by 0x1270DE: test_cipher_aead_test_vectors (in 
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==by 0x12BD65: test_run_funcs (in 
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==by 0x12C139: test_run (in 
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)
==164971==by 0x12AF15: main (in 
/usr/local/src/dovecot-2.3.19.1/src/lib-dcrypt/test-crypto)

==164971==
{
   
   Memcheck:Cond
   obj:/usr/lib/x86_64-linux-gnu/libcrypto.so.3
   obj:/usr/lib/x86_64-linux-gnu/libcrypto.so.3
   fun:EVP_DecryptFinal_ex
   fun:dcrypt_openssl_ctx_sym_final
   fun:dcrypt_ctx_sym_final
   fun:test_cipher_aead_test_vectors
   fun:test_run_funcs
   fun:test_run
   fun:main
}
==164971== 2,304 bytes in 1 blocks are possibly lost in loss record 911 
of 947
==164971==at 0x4848899: malloc (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)

==164971==by 0x4005D97: malloc (rtld-malloc.h:56)
==164971==by 0x4005D97: _dlfo_mappings_segment_allocate 
(dl-find_object.c:217)

==164971==by 0x4005D97: _dl_find_object_update_1 (dl-find_object.c:671)
==164971==by 0x4005D97: _dl_find_object_update (dl-find_object.c:804)
==164971==by 0x400ECCF: dl_open_worker_begin (dl-open.c:735)
==164971==by 0x49DEC27: _dl_catch_exception (dl-error-skeleton.c:208)
==164971==by 0x400DF99: dl_open_worker (dl-open.c:782)
==164971==by 0x49DEC27: _dl_catch_exception (dl-error-skel

Re: Distros based on OpenSSL 3 fail on lib-dcrypt/test-crypto

[Aki Tuomi]

> On 07/06/2022 20:27 Sloane Bernstein  wrote:
> 
> 
> Hello,
> 
> I am getting our Dovecot packages preliminarily ready to support Linux 
> distributions which rely on OpenSSL 3. I notice that even the main dev branch 
> will build, but the test suite fails (among other places) at 
> test_password_change in src/lib-dcrypt/test-crypto.c:
> 
> --
> 
> [root@al9 lib-dcrypt]# ./test-crypto
> test_cipher_test_vectors . : ok
> test_cipher_aead_test_vectors  : ok
> test_hmac_test_vectors ... : ok
> test_load_v1_keys  : ok
> test_load_v1_key . : ok
> test_load_v1_public_key .. : ok
> test_load_v2_key . : ok
> test_load_v2_public_key .. : ok
> test_get_info_v2_key . : ok
> test_gen_and_get_info_rsa_pem  : ok
> test_get_info_rsa_private_key  : ok
> test_get_info_invalid_keys ... : ok
> test_get_info_key_encrypted .. : ok
> test_get_info_pw_encrypted ... : ok
> test-crypto.c:827: Assert failed: ret == TRUE
> Panic: file dcrypt-openssl.c: line 2636 
> (dcrypt_openssl_private_to_public_key): assertion failed: (priv_key != NULL 
> && pub_key_r != NULL)
> Error: Raw backtrace: ./test-crypto(backtrace_append+0x42) [0x445332] -> 
> ./test-crypto(backtrace_get+0x1e) [0x44544e] -> ./test-crypto() [0x42414b] -> 
> ./test-crypto() [0x424181] -> ./test-crypto() [0x412b69] -> 
> .libs/libdcrypt_openssl.so(+0x5f25) [0x7fb61954df25] -> ./test-crypto() 
> [0x41cd9a] -> ./test-crypto() [0x4200af] -> ./test-crypto(test_run+0x4c) 
> [0x420c5c] -> ./test-crypto(main+0x4b) [0x41717b] -> 
> /lib64/libc.so.6(+0x44e50) [0x7fb6195a3e50] -> 
> /lib64/libc.so.6(__libc_start_main+0x7c) [0x7fb6195a3efc] -> 
> ./test-crypto(_start+0x25) [0x417295]
> Aborted (core dumped)
> 
> --
> 
> Looking at how various distros handle this test failure when building 
> packages, they all seem to apply the same patch developed by Red Hat to get 
> this test to pass, attached to 
> https://bugzilla.redhat.com/show_bug.cgi?id=1962035:
> 
> --
> 
> diff -up dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c.opensslv3 
> dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c
> --- dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c.opensslv3 2021-06-03 
> 18:56:52.573174433 +0200
> +++ dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c 2021-06-03 
> 18:56:52.585174274 +0200
> @@ -73,10 +73,30 @@
> 2key algo oid1symmetric algo namesalthash 
> algoroundsE(RSA = i2d_PrivateKey, EC=Private Point)key id
> **/
> 
> +#if OPENSSL_VERSION_MAJOR == 3
> +static EC_KEY *EVP_PKEY_get0_EC_KEYv3(EVP_PKEY *key)
> +{
> + EC_KEY *eck = EVP_PKEY_get1_EC_KEY(key);
> + EVP_PKEY_set1_EC_KEY(key, eck);
> + EC_KEY_free(eck);
> + return eck;
> +}
> +
> +static EC_KEY *EVP_PKEY_get1_EC_KEYv3(EVP_PKEY *key)
> +{
> + EC_KEY *eck = EVP_PKEY_get1_EC_KEY(key);
> + EVP_PKEY_set1_EC_KEY(key, eck);
> + return eck;
> +}
> +
> +#define EVP_PKEY_get0_EC_KEY EVP_PKEY_get0_EC_KEYv3
> +#define EVP_PKEY_get1_EC_KEY EVP_PKEY_get1_EC_KEYv3
> +#else
> #ifndef HAVE_EVP_PKEY_get0
> #define EVP_PKEY_get0_EC_KEY(x) x->pkey.ec
> #define EVP_PKEY_get0_RSA(x) x->pkey.rsa
> #endif
> +#endif
> 
> #ifndef HAVE_OBJ_LENGTH
> #define OBJ_length(o) ((o)->length)
> 
> --
> 
> I presume that either this patch or an equivalent is planned for eventual 
> inclusion into upstream?
> 
> --
> Sloane Bernstein
> Developer I
> cPanel, L.L.C.

Hi!

We'll look into this. Thanks.

Aki

Distros based on OpenSSL 3 fail on lib-dcrypt/test-crypto

[Sloane Bernstein]

Hello,

I am getting our Dovecot packages preliminarily ready to support Linux 
distributions which rely on OpenSSL 3. I notice that even the main dev branch 
will build, but the test suite fails (among other places) at 
test_password_change in src/lib-dcrypt/test-crypto.c:

--

[root@al9 lib-dcrypt]# ./test-crypto
test_cipher_test_vectors . : ok
test_cipher_aead_test_vectors  : ok
test_hmac_test_vectors ... : ok
test_load_v1_keys  : ok
test_load_v1_key . : ok
test_load_v1_public_key .. : ok
test_load_v2_key . : ok
test_load_v2_public_key .. : ok
test_get_info_v2_key . : ok
test_gen_and_get_info_rsa_pem  : ok
test_get_info_rsa_private_key  : ok
test_get_info_invalid_keys ... : ok
test_get_info_key_encrypted .. : ok
test_get_info_pw_encrypted ... : ok
test-crypto.c:827: Assert failed: ret == TRUE
Panic: file dcrypt-openssl.c: line 2636 (dcrypt_openssl_private_to_public_key): 
assertion failed: (priv_key != NULL && pub_key_r != NULL)
Error: Raw backtrace: ./test-crypto(backtrace_append+0x42) [0x445332] -> 
./test-crypto(backtrace_get+0x1e) [0x44544e] -> ./test-crypto() [0x42414b] -> 
./test-crypto() [0x424181] -> ./test-crypto() [0x412b69] -> 
.libs/libdcrypt_openssl.so(+0x5f25) [0x7fb61954df25] -> ./test-crypto() 
[0x41cd9a] -> ./test-crypto() [0x4200af] -> ./test-crypto(test_run+0x4c) 
[0x420c5c] -> ./test-crypto(main+0x4b) [0x41717b] -> /lib64/libc.so.6(+0x44e50) 
[0x7fb6195a3e50] -> /lib64/libc.so.6(__libc_start_main+0x7c) [0x7fb6195a3efc] 
-> ./test-crypto(_start+0x25) [0x417295]
Aborted (core dumped)

--

Looking at how various distros handle this test failure when building packages, 
they all seem to apply the same patch developed by Red Hat to get this test to 
pass, attached to https://bugzilla.redhat.com/show_bug.cgi?id=1962035:

--

diff -up dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c.opensslv3 
dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c
--- dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c.opensslv3   2021-06-03 
18:56:52.573174433 +0200
+++ dovecot-2.3.14/src/lib-dcrypt/dcrypt-openssl.c 2021-06-03 
18:56:52.585174274 +0200
@@ -73,10 +73,30 @@
   2key algo oid1symmetric algo namesalthash 
algoroundsE(RSA = i2d_PrivateKey, EC=Private Point)key id
**/
+#if OPENSSL_VERSION_MAJOR == 3
+static EC_KEY *EVP_PKEY_get0_EC_KEYv3(EVP_PKEY *key)
+{
+  EC_KEY *eck = EVP_PKEY_get1_EC_KEY(key);
+  EVP_PKEY_set1_EC_KEY(key, eck);
+  EC_KEY_free(eck);
+  return eck;
+}
+
+static EC_KEY *EVP_PKEY_get1_EC_KEYv3(EVP_PKEY *key)
+{
+  EC_KEY *eck = EVP_PKEY_get1_EC_KEY(key);
+  EVP_PKEY_set1_EC_KEY(key, eck);
+  return eck;
+}
+
+#define EVP_PKEY_get0_EC_KEY EVP_PKEY_get0_EC_KEYv3
+#define EVP_PKEY_get1_EC_KEY EVP_PKEY_get1_EC_KEYv3
+#else
#ifndef HAVE_EVP_PKEY_get0
#define EVP_PKEY_get0_EC_KEY(x) x->pkey.ec
#define EVP_PKEY_get0_RSA(x) x->pkey.rsa
#endif
+#endif
 #ifndef HAVE_OBJ_LENGTH
#define OBJ_length(o) ((o)->length)

--

I presume that either this patch or an equivalent is planned for eventual 
inclusion into upstream?

--
Sloane Bernstein
Developer I
cPanel, L.L.C.

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Brad Smith]

On 8/13/2021 2:30 PM, Brad Smith wrote:

On 1/16/2021 1:32 PM, Aki Tuomi wrote:

It's not decided yet.

Aki


Any update on this? This is one of very few local patches we keep around.


Aki?


On 16/01/2021 20:16 Brad Smith  wrote:

  I haven't seen anything about this commited upstream yet.

On 1/7/2021 1:45 AM, Aki Tuomi wrote:

Can you try adding this to the file?

#define RLIMIT_AS RLIMIT_DATA

Aki


On 06/01/2021 22:47 Rupert Gallagher  wrote:


OpenBSD


 Original Message 
On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:

Which distro/OS is this?
Aki

Re: Doveadm auth test fails

[Ken Wright]

On Thu, 2022-01-06 at 14:05 -0800, Joseph Tam wrote:
> On Wed, 5 Jan 2022, Ken Wright wrote:
> 
> > Jan  5 22:09:30 grace dovecot: auth: Debug: client passdb out:
> > FAIL#0111#011user=m...@mydomain.com
> 
> Just a wild ass guess, but does your password backend expect "me", or
> "m...@mydomain.com" (which is what it was given).

It was expecting m...@mydomain.com, but that wasn't the problem.  Turns
out PostfixAdmin was hashing the passwords with MD5 and Dovecot was
looking with ARGON.  No wonder I was getting password mismatches!

Ken

Re: Doveadm auth test fails

[Joseph Tam]

On Wed, 5 Jan 2022, Ken Wright wrote:


Jan  5 22:09:30 grace dovecot: auth: Debug: client passdb out:
FAIL#0111#011user=m...@mydomain.com


Just a wild ass guess, but does your password backend expect "me", or
"m...@mydomain.com" (which is what it was given).

Joseph Tam 

Re: Doveadm auth test fails

[Ken Wright]

On Thu, 2022-01-06 at 04:46 +0100, John Fawcett wrote:
> It looks like a mismatch between your dovecot and postfixadmin
> password ARGON2I in dovecot and are using a MD5-crypt scheme in
> postfixadmin. Therefore when you set the password in postfixadmin it
> is saving the password with a different encryption scheme to the one
> that dovecot is using when it verifies the password. I suggest to
> align them. If you change the postfixadmin setting, remember you'll
> have to change the existing passwords that have been stored while
> using a different setting to the dovecot one.

John, you magnificent soandso!  That was indeed the problem.  I changed
PostfixAdmin to ARGON2 and everything worked.  Thank you so much!

> Also one other point (not sure if it's related to the multiple issues
> you've been posting about), but ARGON2 apparently requires a lot of 
> virtual memory. Were you using this previously or did you change to
> it during the server installation you did recently?

I was using it previously.  It was in the tutorial I followed.

Ken

Re: Doveadm auth test fails

[John Fawcett]

On 06/01/2022 04:20, Ken Wright wrote:

On Thu, 2022-01-06 at 03:44 +0100, John Fawcett wrote:

On 06/01/2022 01:16, Ken Wright wrote:

I've been having trouble logging into my email server (postfix
3.4.13, dovecot 2.3.7.2, postfixadmin 3.3.8).  I decided to try the
doveadm auth test, and got the following result:

kwright@grace:~$ sudo doveadm auth test m...@mydomain.com
Password:
passdb: m...@mydomain.com auth failed
extra fields:
    user=m...@mydomain.com

I logged in to PostfixAdmin and made sure I was using the correct
password, but got exactly the same result afterward.  Should I have
restarted Dovecot after changing the password?  I'm totally confused
by this problem; any and all suggestions will be gratefully received!

Ken




Ken

Dovecot does have credential caching, so potentially the info could be
coming from the cache though dovecot uses some logic to understand
when it should do a new query so normally its not necessary to flush
the cache or restart dovecot after changing a password. If you're doing
testing on a non live server in the process of being set up then you
may want to take the cautious approach of restarting dovecot.

about why the command is failing. You may be able to find other
information in the log.

You may want to investigate turning on authentication and password
debugging to progress this problem.

auth_debug = yes

auth_debug_passwords = yes

(and restart dovecot)

Okay, I've done this.


Then try an authentication test again or even a full login test

doveadm auth login username

Those settings will give you information in the log about what dovecot
is doing internally in relation to lookup up the user info and password
including information about password mismatches.

Here's the latest output of tail /var/log/mail.log:

Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug: conn
unix:auth-worker (pid=171742,uid=118): auth-worker<1590>: Handling
PASSV request
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Performing passdb
lookup
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): query: SELECT
username AS user,password FROM mailbox WHERE username =
'm...@mydomain.com' AND active='1'
Jan  5 22:09:28 grace dovecot: auth-worker(218040):
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Password mismatch
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): ARGON2I(password)
!= '$1$c9809462$ecGdXzPm2xqMK0TKngGkc.', try DES-CRYPT scheme instead
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Finished passdb
lookup
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug: conn
unix:auth-worker (pid=171742,uid=118): auth-worker<1590>: Finished
Jan  5 22:09:28 grace dovecot: auth: Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Finished passdb
lookup
Jan  5 22:09:28 grace dovecot: auth: Debug:
auth(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Auth request
finished
Jan  5 22:09:30 grace dovecot: auth: Debug: client passdb out:
FAIL#0111#011user=m...@mydomain.com

I know the password is correct, but it still fails.  I had some
problems getting this mailbox set up in PostfixAdmin; could it be the
database is faulty?

Ken


Ken

It looks like a mismatch between your dovecot and postfixadmin password 
encryption schemes. If I'm reading this correctly you have configured 
ARGON2I in dovecot and are using a MD5-crypt scheme in postfixadmin. 
Therefore when you set the password in postfixadmin it is saving the 
password with a different encryption scheme to the one that dovecot is 
using when it verifies the password. I suggest to align them. If you 
change the postfixadmin setting, remember you'll have to change the 
existing passwords that have been stored while using a different setting 
to the dovecot one.


Also one other point (not sure if it's related to the multiple issues 
you've been posting about), but ARGON2 apparently requires a lot of 
virtual memory. Were you using this previously or did you change to it 
during the server installation you did recently? Here's some more info 
in case you haven't seen it already:


https://doc.dovecot.org/configuration_manual/authentication/password_schemes/

John

Re: Doveadm auth test fails

[Ken Wright]

On Thu, 2022-01-06 at 03:44 +0100, John Fawcett wrote:
> On 06/01/2022 01:16, Ken Wright wrote:
> > I've been having trouble logging into my email server (postfix
> > 3.4.13, dovecot 2.3.7.2, postfixadmin 3.3.8).  I decided to try the
> > doveadm auth test, and got the following result:
> > 
> > kwright@grace:~$ sudo doveadm auth test m...@mydomain.com
> > Password:
> > passdb: m...@mydomain.com auth failed
> > extra fields:
> >    user=m...@mydomain.com
> > 
> > I logged in to PostfixAdmin and made sure I was using the correct
> > password, but got exactly the same result afterward.  Should I have
> > restarted Dovecot after changing the password?  I'm totally confused
> > by this problem; any and all suggestions will be gratefully received!
> > 
> > Ken
> > 
> > 
> > 
> Ken
> 
> Dovecot does have credential caching, so potentially the info could be
> coming from the cache though dovecot uses some logic to understand
> when it should do a new query so normally its not necessary to flush
> the cache or restart dovecot after changing a password. If you're doing
> testing on a non live server in the process of being set up then you
> may want to take the cautious approach of restarting dovecot.
> 
> about why the command is failing. You may be able to find other 
> information in the log.
> 
> You may want to investigate turning on authentication and password 
> debugging to progress this problem.
> 
> auth_debug = yes
> 
> auth_debug_passwords = yes
> 
> (and restart dovecot)

Okay, I've done this.

> Then try an authentication test again or even a full login test
> 
> doveadm auth login username
> 
> Those settings will give you information in the log about what dovecot
> is doing internally in relation to lookup up the user info and password
> including information about password mismatches.

Here's the latest output of tail /var/log/mail.log:

Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug: conn
unix:auth-worker (pid=171742,uid=118): auth-worker<1590>: Handling
PASSV request
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Performing passdb
lookup
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): query: SELECT
username AS user,password FROM mailbox WHERE username =
'm...@mydomain.com' AND active='1'
Jan  5 22:09:28 grace dovecot: auth-worker(218040):
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Password mismatch
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): ARGON2I(password)
!= '$1$c9809462$ecGdXzPm2xqMK0TKngGkc.', try DES-CRYPT scheme instead
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Finished passdb
lookup
Jan  5 22:09:28 grace dovecot: auth-worker(218040): Debug: conn
unix:auth-worker (pid=171742,uid=118): auth-worker<1590>: Finished
Jan  5 22:09:28 grace dovecot: auth: Debug:
sql(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Finished passdb
lookup
Jan  5 22:09:28 grace dovecot: auth: Debug:
auth(m...@mydomain.com,192.168.1.1,<3VfPMuHUrpvAqAEB>): Auth request
finished
Jan  5 22:09:30 grace dovecot: auth: Debug: client passdb out:
FAIL#0111#011user=m...@mydomain.com

I know the password is correct, but it still fails.  I had some
problems getting this mailbox set up in PostfixAdmin; could it be the
database is faulty?

Ken

Re: Doveadm auth test fails

[John Fawcett]

On 06/01/2022 01:16, Ken Wright wrote:

I've been having trouble logging into my email server (postfix 3.4.13,
dovecot 2.3.7.2, postfixadmin 3.3.8).  I decided to try the doveadm
auth test, and got the following result:

kwright@grace:~$ sudo doveadm auth test m...@mydomain.com
Password:
passdb: m...@mydomain.com auth failed
extra fields:
   user=m...@mydomain.com

I logged in to PostfixAdmin and made sure I was using the correct
password, but got exactly the same result afterward.  Should I have
restarted Dovecot after changing the password?  I'm totally confused by
this problem; any and all suggestions will be gratefully received!

Ken




Ken

Dovecot does have credential caching, so potentially the info could be 
coming from the cache though dovecot uses some logic to understand when 
it should do a new query so normally its not necessary to flush the 
cache or restart dovecot after changing a password. If you're doing 
testing on a a non live server in the process of being set up then you 
may want to take the cautious approach of restarting dovecot.


The command output you gave above does not provide useful information 
about why the command is failing. You may be able to find other 
information in the log.


You may want to investigate turning on authentication and password 
debugging to progress this problem.


auth_debug = yes

auth_debug_passwords = yes

(and restart dovecot)

Then try an authentication test again or even a full login test

doveadm auth login username

Those settings will give you information in the log about what dovecot 
is doing internally in relation to lookup up the user info and password 
including information about password mismatches.


John

Doveadm auth test fails

[Ken Wright]

I've been having trouble logging into my email server (postfix 3.4.13,
dovecot 2.3.7.2, postfixadmin 3.3.8).  I decided to try the doveadm
auth test, and got the following result:

kwright@grace:~$ sudo doveadm auth test m...@mydomain.com
Password: 
passdb: m...@mydomain.com auth failed
extra fields:
  user=m...@mydomain.com

I logged in to PostfixAdmin and made sure I was using the correct
password, but got exactly the same result afterward.  Should I have
restarted Dovecot after changing the password?  I'm totally confused by
this problem; any and all suggestions will be gratefully received!

Ken

Re: execve(/usr/bin/sieve-test) failed: Argument list too long

[Aki Tuomi]

> On 02/12/2021 17:16 Patrick Cernko  wrote:
> 
>  
> Hi Dovecot developers,
> 
> while debugging the above error message from sieve-test, I found out, 
> that the content of directive ssl_ca is added as env var SSL_CA by 
> doveconf on execve and sieve-test now uses doveconf.
> 
> In our setup, ssl_ca is set to
> ssl_ca =  on our director servers. We have backend servers with certificates 
> signed by two different CAs and to avoid problems if a backend switches 
> to a different CA, I decided to allow all "known" CAs. The corresponding 
> env var SSL_CA has more than 230500 bytes, which causes execve to fail 
> with error E2BIG.
> 
> I found a workaround for the problem by setting
> ssl_ca =  Where this file contains only the two CAs used atm. However I would like 
> to request a fix for this issue as others might also want to have all 
> "known" CAs set for dovecot director backend connections.
> 
> Best,
> -- 
> Patrick Cernko  +49 681 9325 5815
> Joint Administration: Information Services and Technology
> Max-Planck-Institute fuer Informatik & Softwaresysteme

Hi!

Thanks for reporting this issue, it's related to a known issue and will be 
fixed.

Aki

execve(/usr/bin/sieve-test) failed: Argument list too long

[Patrick Cernko]

Hi Dovecot developers,

while debugging the above error message from sieve-test, I found out, 
that the content of directive ssl_ca is added as env var SSL_CA by 
doveconf on execve and sieve-test now uses doveconf.


In our setup, ssl_ca is set to
ssl_ca = on our director servers. We have backend servers with certificates 
signed by two different CAs and to avoid problems if a backend switches 
to a different CA, I decided to allow all "known" CAs. The corresponding 
env var SSL_CA has more than 230500 bytes, which causes execve to fail 
with error E2BIG.


I found a workaround for the problem by setting
ssl_ca = Where this file contains only the two CAs used atm. However I would like 
to request a fix for this issue as others might also want to have all 
"known" CAs set for dovecot director backend connections.


Best,
--
Patrick Cernko  +49 681 9325 5815
Joint Administration: Information Services and Technology
Max-Planck-Institute fuer Informatik & Softwaresysteme



smime.p7s
Description: S/MIME Cryptographic Signature

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Brad Smith]

On 1/16/2021 1:32 PM, Aki Tuomi wrote:

It's not decided yet.

Aki


Any update on this? This is one of very few local patches we keep around.


On 16/01/2021 20:16 Brad Smith  wrote:

  
I haven't seen anything about this commited upstream yet.


On 1/7/2021 1:45 AM, Aki Tuomi wrote:

Can you try adding this to the file?

#define RLIMIT_AS RLIMIT_DATA

Aki


On 06/01/2021 22:47 Rupert Gallagher  wrote:


OpenBSD


 Original Message 
On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:

Which distro/OS is this?
Aki

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Milan P . Stanić]

On Wed, 2021-08-11 at 00:37, Michael Ströder wrote:
> On 8/10/21 8:59 PM, Timo Sirainen wrote:
> > On 10. Aug 2021, at 19.54, Michael Str?der  wrote:
> >>
> >> Timo,
> >>
> >> On 8/10/21 5:55 PM, Timo Sirainen wrote:
> >>> Well, that's annoying. I thought it would have worked. I wonder if it's
> >>> still some issue with the #if not being right. Can you try once more
> >>> with disabling the #if lines, i.e. just:
> >>
> >> It's currently still building on other big-endian platforms. But at
> >> least S/390 succeeded. (All low-endian platforms now fail but that's
> >> expected.)
> > 
> > The attached patch should work.
> 
> This works. Thank you.

Can confirm that this also works on Alpine Linux.
I pushed it to builders and it passed all of them.

Thank you all for the fixes and help.

-- 
Kind regards

> So I can push the update towards openSUSE Factory now.
> 
> Ciao, Michael.

Re: Test for implicit keep within a sieve script

[Aki Tuomi]

> On 10/08/2021 23:32 Eric Durand  wrote:
> 
> 
> Hi folks,
> 
> Is there a good way to test for an implicit keep in a sieve script ? At the 
> end of my sieve script, if a message still has an implicit keep, it will end 
> up in my inbox, and I would like to push a notification. Right now I am doing 
> this with an ad-hoc variable that is essentially emulating the implicit keep, 
> is there a better way to do this ?
> 
> Thanks!
> Eric

You could use push notification plugin for this. 
https://doc.dovecot.org/configuration_manual/push_notification/#lua-lua

Aki

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Michael Ströder]

On 8/10/21 8:59 PM, Timo Sirainen wrote:
> On 10. Aug 2021, at 19.54, Michael Ströder  wrote:
>>
>> Timo,
>>
>> On 8/10/21 5:55 PM, Timo Sirainen wrote:
>>> Well, that's annoying. I thought it would have worked. I wonder if it's
>>> still some issue with the #if not being right. Can you try once more
>>> with disabling the #if lines, i.e. just:
>>
>> It's currently still building on other big-endian platforms. But at
>> least S/390 succeeded. (All low-endian platforms now fail but that's
>> expected.)
> 
> The attached patch should work.

This works. Thank you.

So I can push the update towards openSUSE Factory now.

Ciao, Michael.

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Michael Ströder]

Timo,

On 8/10/21 5:55 PM, Timo Sirainen wrote:
> Well, that's annoying. I thought it would have worked. I wonder if it's
> still some issue with the #if not being right. Can you try once more
> with disabling the #if lines, i.e. just:

It's currently still building on other big-endian platforms. But at
least S/390 succeeded. (All low-endian platforms now fail but that's
expected.)

> If that doesn't work either, I'd somehow need to get access to a
> big-endian CPU to try to figure out where it's going wrong.

openSUSE build system is open for the public:

Get yourself an account by clicking "Sign  Up" here:
https://build.opensuse.org

You then have a home project home:username in which you can build any
packages you want for a wide range of platforms. The build workers are
often native hardware.

You could branch the existing official devel dovecot23 package and do
whatever tests you want to do:

https://build.opensuse.org/package/show/server:mail/dovecot23

My own package builds are also just a branch of the above where I
prepare the 2.3.16 update:

https://build.opensuse.org/package/show/home:stroeder:network/dovecot23

Let me know if you need further information, though I'm not an OBS expert.

Ciao, Michael.

Test for implicit keep within a sieve script

[Eric Durand]

Hi folks,

Is there a good way to test for an implicit keep in a sieve script  ? At
the end of my sieve script, if a message still has an implicit keep, it
will end up in my inbox, and I would like to push a notification. Right now
I am doing this with an ad-hoc variable that is essentially emulating the
implicit keep, is there a better way to do this ?

Thanks!
Eric

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Timo Sirainen]

On 10. Aug 2021, at 19.54, Michael Ströder  wrote:
> 
> Timo,
> 
> On 8/10/21 5:55 PM, Timo Sirainen wrote:
>> Well, that's annoying. I thought it would have worked. I wonder if it's
>> still some issue with the #if not being right. Can you try once more
>> with disabling the #if lines, i.e. just:
> 
> It's currently still building on other big-endian platforms. But at
> least S/390 succeeded. (All low-endian platforms now fail but that's
> expected.)

The attached patch should work. TIME_T_BITS was originally typoed, should have 
been TIME_T_MAX_BITS. But even that isn't really a good way to check it. 
SIZEOF_VOID_P == 8 should work well enough.



mail-cache-bigendian.diff
Description: Binary data

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Michael Ströder]

On 8/10/21 11:16 AM, Timo Sirainen wrote:
> On 10. Aug 2021, at 10.33, Michael Ströder  wrote:
>>
>> On 8/10/21 10:02 AM, Milan P. Stanić wrote:
>>> I'm trying to upgrade dovecot from version 2.3.15 to 2.3.16 for alpine
>>> linux. Build and 'make check' pass on all alpine architectures except on
>>> s390x which is big-endian while all other are little-endian.
>>
>> You're probably hitting the same issues like me on openSUSE.
>>
>> See Timo's response to that:
>>
>> https://dovecot.org/pipermail/dovecot/2021-August/122787.html
> 
> The attached patch probably helps?

Assuming I've applied the patch correctly it does not help on ppc64 and
S/390:

https://build.opensuse.org/package/show/home:stroeder:network/dovecot23

You can download the complete build log, e.g. deep-link for S/390 build log:

https://build.opensuse.org/build/home:stroeder:network/openSUSE_Factory_zSystems/s390x/dovecot23/_log

Ciao, Michael.

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Timo Sirainen]

On 10. Aug 2021, at 14.17, Michael Ströder  wrote:
> 
> On 8/10/21 11:16 AM, Timo Sirainen wrote:
>> On 10. Aug 2021, at 10.33, Michael Ströder  wrote:
>>> 
>>> On 8/10/21 10:02 AM, Milan P. Stanić wrote:
 I'm trying to upgrade dovecot from version 2.3.15 to 2.3.16 for alpine
 linux. Build and 'make check' pass on all alpine architectures except on
 s390x which is big-endian while all other are little-endian.
>>> 
>>> You're probably hitting the same issues like me on openSUSE.
>>> 
>>> See Timo's response to that:
>>> 
>>> https://dovecot.org/pipermail/dovecot/2021-August/122787.html
>> 
>> The attached patch probably helps?
> 
> Assuming I've applied the patch correctly it does not help on ppc64 and
> S/390:
> 
> https://build.opensuse.org/package/show/home:stroeder:network/dovecot23 
> 

Well, that's annoying. I thought it would have worked. I wonder if it's still 
some issue with the #if not being right. Can you try once more with disabling 
the #if lines, i.e. just:

+static void
+copy_to_buf_last_used(struct mail_cache *cache, buffer_t *dest, bool add_new)
+{
+   size_t offset = offsetof(struct mail_cache_field, last_used);
+//#if defined(WORDS_BIGENDIAN) && TIME_T_BITS > 32
+   offset += sizeof(uint32_t);
+//#endif
+   copy_to_buf(cache, dest, add_new, offset, sizeof(uint32_t));
+}

If that doesn't work either, I'd somehow need to get access to a big-endian CPU 
to try to figure out where it's going wrong.

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Michael Ströder]

On 8/10/21 10:02 AM, Milan P. Stanić wrote:
> I'm trying to upgrade dovecot from version 2.3.15 to 2.3.16 for alpine
> linux. Build and 'make check' pass on all alpine architectures except on
> s390x which is big-endian while all other are little-endian.

You're probably hitting the same issues like me on openSUSE.

See Timo's response to that:

https://dovecot.org/pipermail/dovecot/2021-August/122787.html

Ciao, Michael.

Re: dovecot 2.3.16 fail one test on s390x, alpine linux

[Timo Sirainen]

On 10. Aug 2021, at 10.33, Michael Ströder  wrote:
> 
> On 8/10/21 10:02 AM, Milan P. Stanić wrote:
>> I'm trying to upgrade dovecot from version 2.3.15 to 2.3.16 for alpine
>> linux. Build and 'make check' pass on all alpine architectures except on
>> s390x which is big-endian while all other are little-endian.
> 
> You're probably hitting the same issues like me on openSUSE.
> 
> See Timo's response to that:
> 
> https://dovecot.org/pipermail/dovecot/2021-August/122787.html

The attached patch probably helps?



mail-cache-bigendian.diff
Description: Binary data

dovecot 2.3.16 fail one test on s390x, alpine linux

[Milan P . Stanić]

Hi,

I'm trying to upgrade dovecot from version 2.3.15 to 2.3.16 for alpine
linux. Build and 'make check' pass on all alpine architectures except on
s390x which is big-endian while all other are little-endian.

here is the part from CI build log which fails:

mail cache size corruption ... : ok
0 / 10 tests failed
test-mail-cache-fields.c:50: Assert failed: cache_field.last_used == 
priv->field.last_used && cache_field.decision == priv->field.decision
test-mail-cache-fields.c:65: Assert failed: cache_field.last_used == 
priv->field.last_used && cache_field.decision == priv->field.decision
test-mail-cache-fields.c:94: Assert failed: cache_field.last_used == 
priv->field.last_used && cache_field.decision == priv->field.decision
mail cache fields read-write . : FAILED
1 / 1 tests failed
make[3]: *** [Makefile:1279: check-local] Error 1
make[3]: Leaving directory 
'/builds/alpine/aports/main/dovecot/src/dovecot-2.3.16/src/lib-index'
make[2]: *** [Makefile:1049: check-am] Error 2
make[2]: Target 'check' not remade because of errors.
make[2]: Leaving directory 
'/builds/alpine/aports/main/dovecot/src/dovecot-2.3.16/src/lib-index'
Making check in lib-storage


Full log is here:
https://gitlab.alpinelinux.org/alpine/aports/-/jobs/459182/raw

-- 
Kind regards

Re: Letsencrypt/OpenSSL test - Verify return code: 21

[Oscar del Rio]

On 2021-04-10 12:09 p.m., Brady Shea wrote:


I finally 'fixed' it myself by using the LE 'fullchain.pem' 
certificate as the location for the 'ssl_cert' entry (and chain.pem 
for the ca entry). Previously, it was using the normal cert.pem file 
location. This is still the way it's setup on the other older machine 
and still works fine. Changes-


|ssl_ca = 'fullchain.pem' should work) *ssl_cert = 
previously) ssl_key = 

/etc/letsencrypt/live/README:

`[cert name]/privkey.pem`  : the private key for your certificate.
`[cert name]/fullchain.pem`: the certificate file used in most server 
software.

`[cert name]/chain.pem`    : used for OCSP stapling in Nginx >=1.3.7.
`[cert name]/cert.pem` : will break many server configurations, and 
should not be used

 without reading further documentation

Re: Letsencrypt/OpenSSL test - Verify return code: 21

[Juri Haberland]

On 11/04/2021 01:04, @lbutlr wrote:
> On 10 Apr 2021, at 12:57, Juri Haberland  wrote:
>> On 10/04/2021 19:52, @lbutlr wrote:
>>> On 10 Apr 2021, at 09:55, B Shea  wrote:
>>>> OpenSSL (Ubuntu default/repo version):  1.1.1f  31 Mar 2020
>>> 
>>> There have been a few critical patches to open SSL in the last year, 
>>> including a very important one to 1.1.1k just recently.
>>> 
>>> Not to do with your issue, but I suspect updating both openssl and Dovecot 
>>> are good first steps.
>> 
>> That is the version as distributed by Ubuntu with security fixes
>> backported as usual for most Linux distributions...
> 
> If the date is May 2020, then no, it hasn't.
> 
> As I said, there have been many patches since then, including one very 
> important one very recently (end of march, beginning of April).
> 

$ lsb_release --description
Description:Ubuntu 20.04.2 LTS
$ openssl version
OpenSSL 1.1.1f  31 Mar 2020
$ dpkg -l | grep openssl
ii  openssl1.1.1f-1ubuntu2.3 amd64Secure Sockets Layer
toolkit - cryptographic utility

$ zcat /usr/share/doc/openssl/changelog.Debian.gz | head -n 16
openssl (1.1.1f-1ubuntu2.3) focal-security; urgency=medium

  * SECURITY UPDATE: NULL pointer deref in signature_algorithms processing
- debian/patches/CVE-2021-3449-1.patch: fix NULL pointer dereference in
  ssl/statem/extensions.c.
- debian/patches/CVE-2021-3449-2.patch: teach TLSProxy how to encrypt
  <= TLSv1.2 ETM records in util/perl/TLSProxy/Message.pm.
- debian/patches/CVE-2021-3449-3.patch: add a test to
  test/recipes/70-test_renegotiation.t.
- debian/patches/CVE-2021-3449-4.patch: ensure buffer/length pairs are
  always in sync in ssl/s3_lib.c, ssl/ssl_lib.c,
  ssl/statem/extensions.c, ssl/statem/extensions_clnt.c,
  ssl/statem/statem_clnt.c, ssl/statem/statem_srvr.c.
- CVE-2021-3449

 -- Marc Deslauriers   Mon, 22 Mar 2021
07:37:17 -0400


So yes, it is up-to-date.


Cheers,
  Juri

Re: Letsencrypt/OpenSSL test - Verify return code: 21

[@lbutlr]

On 10 Apr 2021, at 12:57, Juri Haberland  wrote:
> On 10/04/2021 19:52, @lbutlr wrote:
>> On 10 Apr 2021, at 09:55, B Shea  wrote:
>>> OpenSSL (Ubuntu default/repo version):  1.1.1f  31 Mar 2020
>> 
>> There have been a few critical patches to open SSL in the last year, 
>> including a very important one to 1.1.1k just recently.
>> 
>> Not to do with your issue, but I suspect updating both openssl and Dovecot 
>> are good first steps.
> 
> That is the version as distributed by Ubuntu with security fixes
> backported as usual for most Linux distributions...

If the date is May 2020, then no, it hasn't.

As I said, there have been many patches since then, including one very 
important one very recently (end of march, beginning of April).

-- 
Greedo didn't shoot first, motherfucker!

Re: Letsencrypt/OpenSSL test - Verify return code: 21

[Juri Haberland]

On 10/04/2021 19:52, @lbutlr wrote:
> On 10 Apr 2021, at 09:55, B Shea  wrote:
>> OpenSSL (Ubuntu default/repo version):  1.1.1f  31 Mar 2020
> 
> There have been a few critical patches to open SSL in the last year, 
> including a very important one to 1.1.1k just recently.
> 
> Not to do with your issue, but I suspect updating both openssl and Dovecot 
> are good first steps.

That is the version as distributed by Ubuntu with security fixes
backported as usual for most Linux distributions...


Kind regards,
  Juri

Re: Letsencrypt/OpenSSL test - Verify return code: 21

[@lbutlr]

On 10 Apr 2021, at 09:55, B Shea  wrote:
> OpenSSL (Ubuntu default/repo version):  1.1.1f  31 Mar 2020

There have been a few critical patches to open SSL in the last year, including 
a very important one to 1.1.1k just recently.

Not to do with your issue, but I suspect updating both openssl and Dovecot are 
good first steps.

-- 
what is magic actually for?
For fixing things, dummy.

Re: Letsencrypt/OpenSSL test - Verify return code: 21

[Aki Tuomi]

> On 10/04/2021 19:09 Brady Shea  wrote:
> 
> 
> OS: Ubuntu 20.04.2 (on mutli-core VM)
>  Dovecot (Ubuntu default/repo version): 2.3.7.2 (3c910f64b)
>  OpenSSL (Ubuntu default/repo version): 1.1.1f 31 Mar 2020
>  
>  Reproducing-
>  
>  Run: "openssl s_client -showcerts -connect imap.example.com:993 -servername 
> imap.example.com" (using a diff domain obviously)
>  
>  Produces error: "Verify return code: 21 (unable to verify the first 
> certificate)" (Meaning it is missing a CA verify from what I understand?)
>  
>  The "Verify return code: 21" error ONLY came to my attention after I had a 
> customer complain about adding an email account to an Android phone (using 
> the Google/Gmail default email app). -> "Certificate cannot be trusted" was 
> shown by app when verifying imap connection. I could force it to be used, but 
> this still bothered me, obviously. *The same certificate bundle is also used 
> by smtp/postifx and www/nginx and works just fine. Also the openssl test 
> shows 'verified' on both*
>  
>  I am posting to list mainly because on an older version of Dovecot I have 
> running (default repo version for Ubuntu 18), I do not have this problem 
> shown during testing with openssl. I did not have to change the ssl_cert or 
> ssl_ca value in config. It has identical local.conf settings other than that. 
> Granted it is also an older openssl version, too. So, I feel this may be a 
> bug with Dovecot (or possibly OpenSSL).
>  
>  I finally 'fixed' it myself by using the LE 'fullchain.pem' certificate as 
> the location for the 'ssl_cert' entry (and chain.pem for the ca entry). 
> Previously, it was using the normal cert.pem file location. This is still the 
> way it's setup on the other older machine and still works fine. Changes-
>  
>  |ssl_ca =  should work) *ssl_cert =  (was 'cert.pem' previously) ssl_key = 
>   
>  You can also view the problem here for more info : 
> https://superuser.com/a/1640778/47628
>  
>  Thanks ahead for any insight into this..
>  
>  
>  

In 2.2 it was an unfortunate mistake that ssl_ca was concatenated with 
ssl_cert. In 2.3 this was fixed to work as it should, as in, ssl_ca is used to 
*verify* incoming connections and ssl_cert needs to contain the full chain 
certificate.

Aki

Letsencrypt/OpenSSL test - Verify return code: 21

[Brady Shea]

OS: Ubuntu 20.04.2 (on mutli-core VM)
Dovecot (Ubuntu default/repo version):  2.3.7.2 (3c910f64b)
OpenSSL (Ubuntu default/repo version):  1.1.1f  31 Mar 2020

Reproducing-

Run:  "openssl s_client -showcerts -connect imap.example.com:993 
-servername imap.example.com" (using a diff domain obviously)


Produces error: "Verify return code: 21 (unable to verify the first 
certificate)" (Meaning it is missing a CA verify from what I understand?)


The "Verify return code: 21" error ONLY came to my attention after I had 
a customer complain about adding an email account to an Android phone 
(using the Google/Gmail default email app). -> "Certificate cannot be 
trusted" was shown by app when verifying imap connection. I could force 
it to be used, but this still bothered me, obviously. *The same 
certificate bundle is also used by smtp/postifx and www/nginx and works 
just fine. Also the openssl test shows 'verified' on both*


I am posting to list mainly because on an older version of Dovecot I 
have running (default repo version for Ubuntu 18), I do not have this 
problem shown during testing with openssl. I did not have to change the 
ssl_cert or ssl_ca value in config. It has identical local.conf settings 
other than that. Granted it is also an older openssl version, too. So, I 
feel this may be a bug with Dovecot (or possibly OpenSSL).


I finally 'fixed' it myself by using the LE 'fullchain.pem' certificate 
as the location for the 'ssl_cert' entry (and chain.pem for the ca 
entry). Previously, it was using the normal cert.pem file location. This 
is still the way it's setup on the other older machine and still works 
fine. Changes-


|ssl_ca = 'fullchain.pem' should work) *ssl_cert = 
previously) ssl_key = 

You can also view the problem here for more info : 
https://superuser.com/a/1640778/47628


Thanks ahead for any insight into this..

Letsencrypt/OpenSSL test - Verify return code: 21

[B Shea]

OS: Ubuntu 20.04.2 (on mutli-core VM)
Dovecot (Ubuntu default/repo version):  2.3.7.2 (3c910f64b)
OpenSSL (Ubuntu default/repo version):  1.1.1f  31 Mar 2020

Reproducing-

Run:  "openssl s_client -showcerts -connect imap.example.com:993 
-servername imap.example.com" (using a diff domain obviously)


Produces error: "Verify return code: 21 (unable to verify the first 
certificate)" (Meaning it is missing a CA verify from what I understand?)


The "Verify return code: 21" error ONLY came to my attention after I had 
a customer complain about adding an email account to an Android phone 
(using the Google/Gmail default email app). -> "Certificate cannot be 
trusted" was shown by app when verifying imap connection. I could force 
it to be used, but this still bothered me, obviously. *The same 
certificate bundle is also used by smtp/postifx and www/nginx and works 
just fine. Also the openssl test shows 'verified' on both*


I am posting to list mainly because on an older version of Dovecot I 
have running (default repo version for Ubuntu 18), I do not have this 
problem shown during testing with openssl. I did not have to change the 
ssl_cert or ssl_ca value in config. It has identical local.conf settings 
other than that. Granted it is also an older openssl version, too. So, I 
feel this may be a bug with Dovecot (or possibly OpenSSL).


I finally 'fixed' it myself by using the LE 'fullchain.pem' certificate 
as the location for the 'ssl_cert' entry (and chain.pem for the ca 
entry). Previously, it was using the normal cert.pem file location. This 
is still the way it's setup on the other older machine and still works 
fine. Changes-


|ssl_ca = 'fullchain.pem' should work) *ssl_cert = 
previously) ssl_key = 

You can also view the problem here for more info : 
https://superuser.com/a/1640778/47628


Thanks ahead for any insight into this..

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Brad Smith]

Ok. Thanks. Just wanted to make sure it wasn't missed.

On 1/16/2021 1:32 PM, Aki Tuomi wrote:

It's not decided yet.

Aki


On 16/01/2021 20:16 Brad Smith  wrote:

  
I haven't seen anything about this commited upstream yet.


On 1/7/2021 1:45 AM, Aki Tuomi wrote:

Can you try adding this to the file?

#define RLIMIT_AS RLIMIT_DATA

Aki


On 06/01/2021 22:47 Rupert Gallagher  wrote:


OpenBSD


 Original Message 
On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:

Which distro/OS is this?
Aki

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Aki Tuomi]

It's not decided yet. 

Aki

> On 16/01/2021 20:16 Brad Smith  wrote:
> 
>  
> I haven't seen anything about this commited upstream yet.
> 
> On 1/7/2021 1:45 AM, Aki Tuomi wrote:
> > Can you try adding this to the file?
> >
> > #define RLIMIT_AS RLIMIT_DATA
> >
> > Aki
> >
> >> On 06/01/2021 22:47 Rupert Gallagher  wrote:
> >>
> >>
> >> OpenBSD
> >>
> >>
> >>  Original Message 
> >> On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:
> >>
> >> Which distro/OS is this?
> >> Aki

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Brad Smith]

I haven't seen anything about this commited upstream yet.

On 1/7/2021 1:45 AM, Aki Tuomi wrote:

Can you try adding this to the file?

#define RLIMIT_AS RLIMIT_DATA

Aki


On 06/01/2021 22:47 Rupert Gallagher  wrote:


OpenBSD


 Original Message 
On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:

Which distro/OS is this?
Aki

Re: status of test code

[Aki Tuomi]

Thanks for the update, we'll check it out and see if there is something to do.

Aki

> On 10/01/2021 23:34 st...@keptprivate.com  wrote:
> 
> 
> Update:
> 
> I was finally able to build 2.3.13 on centos 8 (8.3). I managed this by going 
> back to the qmailtoaster spec file, removing a few things no longer relevant 
> (vpopmail) and disabling all the tests. Most tests were still running but 
> there were also many that did not. The good news is the resulting executable 
> in the RPM no longer complains about not being able to find libdovecot.so 
> (http://libdovecot.so). i've done some basic testing on imap and everything 
> appears to be working.
> 
> Someone who maintains the tests and rpm build should really have a look. 
> Doing a build on a fresh centos 8 machine, as I was able to with the 
> qmailtoaster source rpm, should really be much simpler. My impression is the 
> current spec file may have edits that were eroneously committed?
> 
> Steve
> 
> Sent from my T-Mobile 4G LTE device
> 
> -- Original message--
> From:st...@keptprivate.com
> Date:Sat, Jan 9, 2021 3:42 PM
> To:dovecot@dovecot.org;
> Cc:
> Subject:status of test code
> 
> Hi,
> 
> I'm continuing to try to build 2.3.13 with a source RPM.
> 
> At this point I've taken the source zip file and I'm working with the 
> previously working qmailtoaster SPEC file and RPM build process.
> 
> The toaster SPEC file runs the built-in dovecot tests after build... 2.3.11 
> would make it through
>  all the tests with a few minor exceptions.
> 
> 2.3.13 seems no longer able to run the test is lib-ssl-iostream or lib-lua 
> (and perhaps others, but that's as far as I've gotten).
> 
> I can selectively disable the tests to make progress, but it raises the 
> question of what the plans are for the built-in tests.
> 
> Also, I continue to not be able to find where all the testing is turned 
> on/off at once? I'm sure it will be obvious when someone tells me but 
> please tell me, because I'm pulling my hair out.
> 
> Steve
> 
>

Re: status of test code

[st...@keptprivate.com]

Update:I was finally able to build 2.3.13 on centos 8 (8.3). I managed this by 
going back to the qmailtoaster spec file, removing a few things no longer 
relevant (vpopmail) and disabling all the tests. Most tests were still running 
but there were also many that did not. The good news is the resulting 
executable in the RPM no longer complains about not being able to find 
libdovecot.so. i've done some basic testing on imap and everything appears to 
be working.Someone who maintains the tests and rpm build should really have a 
look. Doing a build on a fresh centos 8 machine, as I was able to with the 
qmailtoaster source rpm, should really be much simpler. My impression is the 
current spec file may have edits that were eroneously committed? SteveSent from 
my T-Mobile 4G LTE device-- Original message--From: 
steve@keptprivate.comDate: Sat, Jan 9, 2021 3:42 PMTo: dovecot@dovecot.org;Cc: 
Subject:status of test codeHi,

I'm continuing to try to build 2.3.13 with a source RPM.

At this
 point I've taken the source zip file and I'm working with the previously 
working qmailtoaster SPEC file and RPM build process.

The toaster SPEC file runs the built-in dovecot tests after build... 2.3.11 
would make it through all the tests with a few minor exceptions.

2.3.13 seems no longer able to run the test is lib-ssl-iostream or lib-lua (and 
perhaps others, but that's as far as I've gotten).

I can selectively disable the tests to make progress, but it raises the 
question of what the plans are for the built-in tests.

Also, I continue to not be able to find where all the testing is turned on/off 
at once? I'm sure it will be obvious when someone tells me but 
please tell me, because I'm pulling my hair out.

Steve

Re: status of test code

[Eric Broch]

make check

On 1/9/2021 11:47 AM, st...@keptprivate.com wrote:

Hi,

I'm continuing to try to build 2.3.13 with a source RPM.

At this point I've taken the source zip file and I'm working with the 
previously working qmailtoaster SPEC file and RPM build process.

The toaster SPEC file runs the built-in dovecot tests after build... 2.3.11 
would make it through all the tests with a few minor exceptions.

2.3.13 seems no longer able to run the test is lib-ssl-iostream or lib-lua (and 
perhaps others, but that's as far as I've gotten).

I can selectively disable the tests to make progress, but it raises the 
question of what the plans are for the built-in tests.

Also, I continue to not be able to find where all the testing is turned on/off 
at once? I'm sure it will be obvious when someone tells me but
please tell me, because I'm pulling my hair out.

Steve

status of test code

[steve]

Hi,

I'm continuing to try to build 2.3.13 with a source RPM.

At this point I've taken the source zip file and I'm working with the 
previously working qmailtoaster SPEC file and RPM build process.

The toaster SPEC file runs the built-in dovecot tests after build... 2.3.11 
would make it through all the tests with a few minor exceptions.

2.3.13 seems no longer able to run the test is lib-ssl-iostream or lib-lua (and 
perhaps others, but that's as far as I've gotten).

I can selectively disable the tests to make progress, but it raises the 
question of what the plans are for the built-in tests.

Also, I continue to not be able to find where all the testing is turned on/off 
at once? I'm sure it will be obvious when someone tells me but 
please tell me, because I'm pulling my hair out.

Steve

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Rupert Gallagher]

It compiles.

--- ./src/lib/test-file-cache.c.origWed Jan  6 19:11:47 2021
+++ ./src/lib/test-file-cache.c Thu Jan  7 11:38:03 2021
@@ -254,6 +254,11 @@
test_assert(size == 0);
test_assert(map == NULL);

+   /* OpenBSD does not support RLIMIT_AS */
+   #ifndef HAVE_RLIMIT_AS
+   #define RLIMIT_AS RLIMIT_DATA
+   #endif
+
/* temporarily set a small memory limit to make mmap attempt fail */
struct rlimit rl_cur;
test_assert(getrlimit(RLIMIT_AS, _cur) == 0);



‐‐‐ Original Message ‐‐‐
On Thursday, January 7, 2021 6:45 AM, Aki Tuomi  
wrote:

> Can you try adding this to the file?
>
> #define RLIMIT_AS RLIMIT_DATA
>
> Aki
>
> > On 06/01/2021 22:47 Rupert Gallagher r...@protonmail.com wrote:
> > OpenBSD
> >  Original Message 
> > On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:
> > Which distro/OS is this?
> > Aki

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Aki Tuomi]

Can you try adding this to the file?

#define RLIMIT_AS RLIMIT_DATA 

Aki

> On 06/01/2021 22:47 Rupert Gallagher  wrote:
> 
> 
> OpenBSD
> 
> 
>  Original Message 
> On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:
> 
> Which distro/OS is this?
> Aki

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Rupert Gallagher]

OpenBSD

 Original Message 
On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:

Which distro/OS is this?
Aki

Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Aki Tuomi]

> On 06/01/2021 21:34 Rupert Gallagher  wrote:
> 
>  
> test-file-cache.c:259:24: error: use of undeclared identifier 'RLIMIT_AS'
> test_assert(getrlimit(RLIMIT_AS, _cur) == 0);
>   ^
> test-file-cache.c:267:24: error: use of undeclared identifier 'RLIMIT_AS'
> test_assert(setrlimit(RLIMIT_AS, _new) == 0);
>   ^
> test-file-cache.c:270:24: error: use of undeclared identifier 'RLIMIT_AS'
> test_assert(setrlimit(RLIMIT_AS, _cur) == 0);
>   ^
> test-file-cache.c:276:24: error: use of undeclared identifier 'RLIMIT_AS'
> test_assert(setrlimit(RLIMIT_AS, _new) == 0);
>   ^
> test-file-cache.c:279:24: error: use of undeclared identifier 'RLIMIT_AS'
> test_assert(setrlimit(RLIMIT_AS, _cur) == 0);
>   ^

Which distro/OS is this?

Aki

test-file-cache.c needs #ifdef HAVE_RLIMIT_AS

[Rupert Gallagher]

test-file-cache.c:259:24: error: use of undeclared identifier 'RLIMIT_AS'
test_assert(getrlimit(RLIMIT_AS, _cur) == 0);
  ^
test-file-cache.c:267:24: error: use of undeclared identifier 'RLIMIT_AS'
test_assert(setrlimit(RLIMIT_AS, _new) == 0);
  ^
test-file-cache.c:270:24: error: use of undeclared identifier 'RLIMIT_AS'
test_assert(setrlimit(RLIMIT_AS, _cur) == 0);
  ^
test-file-cache.c:276:24: error: use of undeclared identifier 'RLIMIT_AS'
test_assert(setrlimit(RLIMIT_AS, _new) == 0);
  ^
test-file-cache.c:279:24: error: use of undeclared identifier 'RLIMIT_AS'
test_assert(setrlimit(RLIMIT_AS, _cur) == 0);
  ^

Re: Sieve body test

[@lbutlr]

On 09 Nov 2020, at 14:45, Stephan Bosch  wrote:
> On 27/10/2020 15:30, @lbutlr wrote:
>> On 26 Oct 2020, at 21:04, Stephan Bosch  wrote:
>>> On 23/10/2020 13:22, @lbutlr wrote:
>>>> On 22 Oct 2020, at 19:09, Stephan Bosch  wrote:
>>>>> You need to include the extprograms plugin:
>>>> I have, and vnf.dovecot.pipe doesn't give the error.
>>>> 
>>>>   sieve_plugins = sieve_imapsieve sieve_extprograms
>>>> 
>>>> ¯\_(ツ)_/¯
>>>> 
>>>> I am not using filter now though, so I haven't try to track down what the 
>>>> issue is.
>>> And you also need to add vnd.dovecot.filter to sieve_extensions (or 
>>> sieve_global_extensions).
>> Ah, yes, so I do. I only had .pipe there. While I am here, does _global_ 
>> mean that they do not need to be listed in the requires header?
> 
> No, it means it can only be used from global (administrator-controlled) 
> scripts, like those configured for sieve_before/sieve_after. So, the normal 
> user scripts that are uploaded through ManageSieve cannot use it when it is 
> only listed as global.

Thanks, I did figure that out. It would be nice if you could somehow set 
per-user access to certain extensions.

>> That's good, I'm working on a. Filter to restyle some html emails that I get 
>> to eliminate the white backgrounds, and filter is going to be necessary for 
>> that to work.
>> 
>> Something along the lines of
>> 
>> if allof ( header :contains "from" "someone",
>>header :contains "to" "me".
>>Header :contains "Subject" "Stupid HTML" ) {
>> 
>>   if body :raw :contains "" {
>> filter :try "darkmode.sh";
>>   }
>> }
> 
> You could also check the content-type header, rather than inspecting the body 
> for a tell-tale HTML tag.

Yes. I originally was thinking I would be able to do the substitution in the 
sieve itself so was searching fo the bit I would be replacing. I don't think it 
matters either way. The match is successful and the shell script is called.

>> darkmode.sh:
>> #!/bin/sh
>> sed -e '||* {color:white !important; background-color: black 
>> !important; } |'
>> 
>> (Not that I have even begun to test that)
> 
> I am not too familiar with sed, but as long as this script reads the raw mail 
> from stdin and writes the modified mail to stdout, it should work.

Yes, it should. It works from the command line, but fails in sieve.

I've put it aside for now, and may just use a milter in postfix to simply strip 
the HTML portion out of the email entirely, though that is less than ideal.


-- 
'I don't see why everyone depends on me. I'm not dependable. Even I
don't depend on me, and I'm me.'

Re: Sieve body test

[Stephan Bosch]

On 27/10/2020 15:30, @lbutlr wrote:

On 26 Oct 2020, at 21:04, Stephan Bosch  wrote:

On 23/10/2020 13:22, @lbutlr wrote:

On 22 Oct 2020, at 19:09, Stephan Bosch  wrote:

You need to include the extprograms plugin:

I have, and vnf.dovecot.pipe doesn't give the error.

   sieve_plugins = sieve_imapsieve sieve_extprograms

¯\_(ツ)_/¯

I am not using filter now though, so I haven't try to track down what the issue 
is.

And you also need to add vnd.dovecot.filter to sieve_extensions (or 
sieve_global_extensions).

Ah, yes, so I do. I only had .pipe there. While I am here, does _global_ mean 
that they do not need to be listed in the requires header?


No, it means it can only be used from global (administrator-controlled) 
scripts, like those configured for sieve_before/sieve_after. So, the 
normal user scripts that are uploaded through ManageSieve cannot use it 
when it is only listed as global.


If you want implicit availability without require, you'll need to add it 
to sieve_implicit_extensions=. However, such a configuration is 
non-standard and therefore not recommended (only to provide migration 
from other Sieve interpreters that didn't follow the standard very closely).



That's good, I'm working on a. Filter to restyle some html emails that I get to 
eliminate the white backgrounds, and filter is going to be necessary for that 
to work.

Something along the lines of

if allof ( header :contains "from" "someone",
header :contains "to" "me".
Header :contains "Subject" "Stupid HTML" ) {

   if body :raw :contains "" {
 filter :try "darkmode.sh";
   }
}


You could also check the content-type header, rather than inspecting the 
body for a tell-tale HTML tag.



darkmode.sh:
#!/bin/sh
sed -e '||* {color:white !important; background-color: black !important; } 
|'

(Not that I have even begun to test that)



I am not too familiar with sed, but as long as this script reads the raw 
mail from stdin and writes the modified mail to stdout, it should work.


Regards,

Stephan.

Re: Sieve body test

[@lbutlr]

On 26 Oct 2020, at 21:04, Stephan Bosch  wrote:
> On 23/10/2020 13:22, @lbutlr wrote:
>> On 22 Oct 2020, at 19:09, Stephan Bosch  wrote:
>>> You need to include the extprograms plugin:
>> I have, and vnf.dovecot.pipe doesn't give the error.
>> 
>>   sieve_plugins = sieve_imapsieve sieve_extprograms
>> 
>> ¯\_(ツ)_/¯
>> 
>> I am not using filter now though, so I haven't try to track down what the 
>> issue is.
> 
> And you also need to add vnd.dovecot.filter to sieve_extensions (or 
> sieve_global_extensions).

Ah, yes, so I do. I only had .pipe there. While I am here, does _global_ mean 
that they do not need to be listed in the requires header?

That's good, I'm working on a. Filter to restyle some html emails that I get to 
eliminate the white backgrounds, and filter is going to be necessary for that 
to work.

Something along the lines of

if allof ( header :contains "from" "someone",
   header :contains "to" "me".
   Header :contains "Subject" "Stupid HTML" ) {

  if body :raw :contains "" {
filter :try "darkmode.sh";
  }
}

darkmode.sh:
#!/bin/sh
sed -e '||* {color:white !important; background-color: black 
!important; } |'

(Not that I have even begun to test that)

-- 
[Unused] "Are you pondering what I'm pondering?"

Pinky: I think so, Brain, but she'd never leave Mickey.
Brain: I thought we agreed never to discuss that!

Re: Sieve body test

[Stephan Bosch]

On 23/10/2020 13:22, @lbutlr wrote:

On 22 Oct 2020, at 19:09, Stephan Bosch  wrote:

You need to include the extprograms plugin:

I have, and vnf.dovecot.pipe doesn't give the error.

   sieve_plugins = sieve_imapsieve sieve_extprograms

¯\_(ツ)_/¯

I am not using filter now though, so I haven't try to track down what the issue 
is.


And you also need to add vnd.dovecot.filter to sieve_extensions (or 
sieve_global_extensions).


Regards,

Stephan.

Re: Sieve body test

[@lbutlr]

On 22 Oct 2020, at 19:09, Stephan Bosch  wrote:
> You need to include the extprograms plugin:

I have, and vnf.dovecot.pipe doesn't give the error.

  sieve_plugins = sieve_imapsieve sieve_extprograms

¯\_(ツ)_/¯ 

I am not using filter now though, so I haven't try to track down what the issue 
is.

-- 
Romy: All I've had to eat for the past six days are Gummi Bears, jelly beans,
and candy corns.
Michelle: I wish I had your discipline.

Re: Sieve body test

[Stephan Bosch]

On 20/10/2020 23:37, @lbutlr wrote:

On 20 Oct 2020, at 13:46, @lbutlr  wrote:

It looks like what I need to do is enable and use vnd.dovecot.filter

error: require command: unknown Sieve capability `vnd.dovecot.filter'.

Is this not available to a user? I guess I can put the in global, but ick.


You need to include the extprograms plugin:

https://doc.dovecot.org/configuration_manual/sieve/plugins/extprograms/

The language extension is described here:

https://raw.githubusercontent.com/dovecot/pigeonhole/master/doc/rfc/spec-bosch-sieve-extprograms.txt

Regards,

Stephan.

Re: Sieve body test

[@lbutlr]

On 20 Oct 2020, at 13:46, @lbutlr  wrote:
> 
> It looks like what I need to do is enable and use vnd.dovecot.filter

error: require command: unknown Sieve capability `vnd.dovecot.filter'.

Is this not available to a user? I guess I can put the in global, but ick.

-- 
he'd moved like music, like someone dancing to a rhythm inside his
head. And his face for a moment in the moonlight was the skull of
an angel...

Sieve body test

[@lbutlr]

I have an email where I need to edit the body. I know this is generally a bad 
idea, but in this case I need to do it. The email comes in automatically every 
week or two, and so I thought that SIEVE would be the way to go.

if header :contains "from" "theaddress@tehdomain" {
if body :raw :contains "A string" {
  # Magic happens here
}
}

It looks like what I need to do is enable and use vnd.dovecot.filter to pipe 
the message to a script. (Er. | not vnd.dovecot.pipe)

So, if I wanted to transform the message so that the string "foobar13" was 
changed to "foo-bar-13"

I would add 

   filter :try "myfoobarfix.sh" 

After "magic happens here">

OK so far?

Now, what are the requirements on the executable script? Would it literally be 
as simple as an executable file that simply said

sed -e '|foobar13|foo-bar-13|g'

Or does it need to be a shebang script and take input on $1 and … ? 

And lastly, where do the executable scripts need to be? 
https://raw.githubusercontent.com/dovecot/pigeonhole/master/doc/rfc/spec-bosch-sieve-extprograms.txt
 says "the external programs cannot be chosen arbitrarily; the available 
programs are restricted through administrator configuration", but no details on 
exactly how that is configured.


-- 
"Are you pondering what I'm pondering?"
Pinky: I think so, Brain. But if I put on two tutu's, would I really
be wearing a four-by-four?
Brain: Why do I even bother asking?
Pinky: I dunno, Brain. Maybe it's all part of some huge, cosmic
plot formula!

Test on sending only

[Chris Bennett]

I had to move off of a server to this one too fast.
Having problems

If this goes through, if someone could reply to
ch...@bennettconstruction.us instead of on-list.

Thanks,
Chris Bennett

Re: Sieve test string and case sensitivity

[Stephan Bosch]

On 22/05/2020 15:37, Kim Minh Kaplan wrote:

Hello,

I have found that Pigeonhole comes with an extensive testsuite against
the Sieve RFCs. As I am working on a personal Sieve project I decided to
run my tool on this testsuite and it stumbled on "Basic assignment:
string test failed"[1].

Pigeonhole defaults to comparator "i;octet"[2] for the string test. But
Sieve says that the default comparator should be "i;ascii-casemap"[3].
Did I miss some other part of the standard? Can you point me in the
right direction?

Thank you,
Kim Minh.

[1]: 
https://github.com/dovecot/pigeonhole/blob/master/tests/extensions/variables/basic.svtest#L102
[2]: 
https://github.com/dovecot/pigeonhole/blob/master/src/lib-sieve/plugins/variables/tst-string.c#L92
[3]: https://tools.ietf.org/html/rfc5228#section-2.7.3


Looks like you found an ancient bug. Tracking internally as DOP-1902.

Regards,

Stephan.

Sieve test string and case sensitivity

[Kim Minh Kaplan]

Hello,

I have found that Pigeonhole comes with an extensive testsuite against
the Sieve RFCs. As I am working on a personal Sieve project I decided to
run my tool on this testsuite and it stumbled on "Basic assignment:
string test failed"[1].

Pigeonhole defaults to comparator "i;octet"[2] for the string test. But
Sieve says that the default comparator should be "i;ascii-casemap"[3].
Did I miss some other part of the standard? Can you point me in the
right direction?

Thank you,
Kim Minh.

   [1]: 
https://github.com/dovecot/pigeonhole/blob/master/tests/extensions/variables/basic.svtest#L102
   [2]: 
https://github.com/dovecot/pigeonhole/blob/master/src/lib-sieve/plugins/variables/tst-string.c#L92
   [3]: https://tools.ietf.org/html/rfc5228#section-2.7.3

Re: [PATCH] lib-imap: imap-bodystructure: add test with empty header field

[Simon Ser]

On Tuesday, March 3, 2020 9:00 PM, Timo Sirainen  wrote:

> On 3. Mar 2020, at 20.38, Simon Ser cont...@emersion.fr wrote:
>
> > This causes the body structure to be incorrect. The RFC says it's fine o
> > have empty header field values.
>
> The problem isn't empty header field. It's that the mail is missing 
> Mime-Version header. If that doesn't exist, then the Content-* headers can be 
> ignored. But because there are so many broken mails, Dovecot also allows it 
> to be missing as long as there is Content-Type header. Your test mail has 
> neither of these headers. It's arguable that Dovecot should parse Content-* 
> headers regardless of other headers, but I don't think the current code is 
> violating any RFCs.

Oh, sorry, I thought this caused by the empty header field.

The e-mail found in the wild doesn't have Mime-Version, so it would
probably be a good idea not to ignore Content-Transfer-Encoding indeed.

Re: [PATCH] lib-imap: imap-bodystructure: add test with empty header field

[Timo Sirainen]

On 3. Mar 2020, at 20.38, Simon Ser  wrote:
> 
> This causes the body structure to be incorrect. The RFC says it's fine o
> have empty header field values.

The problem isn't empty header field. It's that the mail is missing 
Mime-Version header. If that doesn't exist, then the Content-* headers can be 
ignored. But because there are so many broken mails, Dovecot also allows it to 
be missing as long as there is Content-Type header. Your test mail has neither 
of these headers. It's arguable that Dovecot should parse Content-* headers 
regardless of other headers, but I don't think the current code is violating 
any RFCs.

Re: [PATCH] lib-imap: imap-bodystructure: add test with empty header field

[Aki Tuomi]

Hi!

Thanks for the patch, we'll look into it.

Aki

> On 03/03/2020 20:38 Simon Ser  wrote:
> 
>  
> This causes the body structure to be incorrect. The RFC says it's fine o
> have empty header field values.
> ---
> 
> This just adds a failing test, inspired from an e-mail spotted in the
> wild. Ideas welcome to fix it.
> 
>  src/lib-imap/test-imap-bodystructure.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/src/lib-imap/test-imap-bodystructure.c 
> b/src/lib-imap/test-imap-bodystructure.c
> index 6f456a44530b..b8f215d689c4 100644
> --- a/src/lib-imap/test-imap-bodystructure.c
> +++ b/src/lib-imap/test-imap-bodystructure.c
> @@ -41,6 +41,19 @@ struct parse_test parse_tests[] = {
>   "\"text\" \"plain\" (\"charset\" \"utf-8\") NIL NIL 
> \"8bit\" 8 2 NIL NIL NIL NIL",
>   .body =
>   "\"text\" \"plain\" (\"charset\" \"utf-8\") NIL NIL 
> \"8bit\" 8 2"
> + },{
> + .message =
> + "From: u...@domain.org\n"
> + "Date: Sat, 24 Mar 2017 23:00:00 +0200\n"
> + "X-Spam-Level:\n"
> + "Content-Transfer-Encoding: quoted-printable\n"
> + "\n"
> + "body\n"
> + "\n",
> + .bodystructure =
> + "\"text\" \"plain\" (\"charset\" \"us-ascii\") NIL NIL 
> \"quoted-printable\" 8 2 NIL NIL NIL NIL",
> + .body =
> + "\"text\" \"plain\" (\"charset\" \"us-ascii\") NIL NIL 
> \"quoted-printable\" 8 2"
>   },{
>   .message =
>   "From: u...@domain.org\n"
> --
> 2.25.1

[PATCH] lib-imap: imap-bodystructure: add test with empty header field

[Simon Ser]

This causes the body structure to be incorrect. The RFC says it's fine o
have empty header field values.
---

This just adds a failing test, inspired from an e-mail spotted in the
wild. Ideas welcome to fix it.

 src/lib-imap/test-imap-bodystructure.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/src/lib-imap/test-imap-bodystructure.c 
b/src/lib-imap/test-imap-bodystructure.c
index 6f456a44530b..b8f215d689c4 100644
--- a/src/lib-imap/test-imap-bodystructure.c
+++ b/src/lib-imap/test-imap-bodystructure.c
@@ -41,6 +41,19 @@ struct parse_test parse_tests[] = {
"\"text\" \"plain\" (\"charset\" \"utf-8\") NIL NIL 
\"8bit\" 8 2 NIL NIL NIL NIL",
.body =
"\"text\" \"plain\" (\"charset\" \"utf-8\") NIL NIL 
\"8bit\" 8 2"
+   },{
+   .message =
+   "From: u...@domain.org\n"
+   "Date: Sat, 24 Mar 2017 23:00:00 +0200\n"
+   "X-Spam-Level:\n"
+   "Content-Transfer-Encoding: quoted-printable\n"
+   "\n"
+   "body\n"
+   "\n",
+   .bodystructure =
+   "\"text\" \"plain\" (\"charset\" \"us-ascii\") NIL NIL 
\"quoted-printable\" 8 2 NIL NIL NIL NIL",
+   .body =
+   "\"text\" \"plain\" (\"charset\" \"us-ascii\") NIL NIL 
\"quoted-printable\" 8 2"
},{
.message =
"From: u...@domain.org\n"
--
2.25.1

Re: [EXT] Re: Test failure on ARM: backtrace_append

[Aki Tuomi]

So the problem is that we got no backtrace at all, which means that your
system is not working as expected. If you have no libunwind installed
(with headers) then it will use libc backtrace get, which apparently on
your system is producing failure. You can try adding
-UHAVE_BACKTRACE_SYMBOLS and -UHAVE_WALKCONTEXT to EXTRA_CFLAGS, this
will disable backtrace_get in dovecot with no other side effects.

So basically, ./configure ... EXTRA_CFLAGS="-UHAVE_BACKTRACE_SYMBOLS
-UHAVE_WALKCONTEXT" or remove them from config.h before compiling.

Aki

On 21.2.2020 14.23, Julien Lepiller wrote:
> Le Fri, 21 Feb 2020 07:25:15 +0200 (EET),
> Aki Tuomi  a écrit :
>
>> Thank you,
>>
>> as I don't have arm at hand, can you provide
>>
>> gdb .test-lib core
>> bt full
>>
>> output?
>> ---
>> Aki Tuomi
>>
> There you are (sorry for the long file names, that's how guix works,
> it's expected):
>
> [New LWP 21501]
> Core was generated by `./test-lib'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0xb6e24d30 in strchr () from
> /gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
> (gdb) bt full
> #0  0xb6e24d30 in strchr () from
> /gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
> No symbol table info available.
> #1  0xb6e26094 in strstr () from
> /gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
> No symbol table info available.
> #2  0x000144fe in test_backtrace_get () at test-backtrace.c:45
> bt = 0x0
> bt = 
> #3  test_backtrace () at test-backtrace.c:56
> No locals.
> #4  0x000353a4 in test_run_named_funcs (tests=tests@entry=0x6608c
> , match=match@entry=0x6ddcc "") at test-common.c:288
> _data_stack_cur_id = 2
> i = 
> #5  0x00035bf0 in test_run_named_with_fatals (match=0x6ddcc "",
> tests=0x6608c , fatals=0x6603c ) at
> test-common.c:370
> No locals.
> #6  0xb6de6426 in __libc_start_main () from
> /gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
> No symbol table info available.
> #7  0x00013268 in _start ()
> No symbol table info available.
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> (gdb) 
>

Re: Test failure on ARM: backtrace_append

[Julien Lepiller]

Le Fri, 21 Feb 2020 07:25:15 +0200 (EET),
Aki Tuomi  a écrit :

> Thank you,
> 
> as I don't have arm at hand, can you provide
> 
> gdb .test-lib core
> bt full
> 
> output?
> ---
> Aki Tuomi
> 

There you are (sorry for the long file names, that's how guix works,
it's expected):

[New LWP 21501]
Core was generated by `./test-lib'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb6e24d30 in strchr () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
(gdb) bt full
#0  0xb6e24d30 in strchr () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
No symbol table info available.
#1  0xb6e26094 in strstr () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
No symbol table info available.
#2  0x000144fe in test_backtrace_get () at test-backtrace.c:45
bt = 0x0
    bt = 
#3  test_backtrace () at test-backtrace.c:56
No locals.
#4  0x000353a4 in test_run_named_funcs (tests=tests@entry=0x6608c
, match=match@entry=0x6ddcc "") at test-common.c:288
_data_stack_cur_id = 2
i = 
#5  0x00035bf0 in test_run_named_with_fatals (match=0x6ddcc "",
tests=0x6608c , fatals=0x6603c ) at
test-common.c:370
No locals.
#6  0xb6de6426 in __libc_start_main () from
/gnu/store/n7c20pjm6q1xq1gqjqzzys1yk9fy7n1k-glibc-2.29/lib/libc.so.6
No symbol table info available.
#7  0x00013268 in _start ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt
stack?)
(gdb) 

Re: Test failure on ARM: backtrace_append

[Aki Tuomi]

 
 
  
   
  
  
   
On 20/02/2020 22:49 Julien Lepiller <
jul...@lepiller.eu> wrote:
   
   

   
   

   
   
Le 20 février 2020 13:37:20 GMT-05:00, Aki Tuomi <
aki.tu...@open-xchange.com> a écrit :
   
   
>
   
   
>> On 20/02/2020 20:31 Julien Lepiller <
jul...@lepiller.eu> wrote:
   
   
>>
   
   
>>
   
   
>> Le 20 février 2020 12:58:52 GMT-05:00, Aki Tuomi
   
   
><
aki.tu...@open-xchange.com> a écrit :
   
   
>> >
   
   
>> >> On 20/02/2020 18:56 Julien Lepiller <
jul...@lepiller.eu> wrote:
   
   
>> >>
   
   
>> >>
   
   
>> >> Hi,
   
   
>> >>
   
   
>> >> I am a packager in Guix and user of dovecot on an ARM server
   
   
>(armhf).
   
   
>> >The Guix package fails to build because of a test error (see the
   
   
>last
   
   
>> >lines of the full build log:
   
   
>>
   
   
>>
https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3).
   
   
>> >As the name suggests, this is dovecot 2.3.9.3, the latest version.
   
   
>> >Previous versions built fine, as well as the same version on x86 and
   
   
>> >x86_64. Note that the build on guix's build farm was done in a qemu
   
   
>vm,
   
   
>> >but I got the same test failure on real hardware.
   
   
>> >>
   
   
>> >> I'm not sure what the best course of action is. Did I find a
   
   
>> >legitimate bug, or should I simply ignore that test for that
   
   
>> >architecture? Dovecot itself seems to be running fine when I ignore
   
   
>the
   
   
>> >tests.
   
   
>> >>
   
   
>> >> Thanks for any guidance you could provide!
   
   
>> >
   
   
>> >(sorry for the previous mail, client acted up...)
   
   
>> >
   
   
>> >Can you provide backtrace for the core file? This seems to be
   
   
>related
   
   
>> >to libunwind somehow.
   
   
>> >
   
   
>> >Aki
   
   
>>
   
   
>> I can try, but it will take me some time to rebuild. I forgot to keep
   
   
>the previous attempts. I think this is unrelated to libunwind since the
   
   
>asserts that fail are in the #elif case for libunwind. We don't build
   
   
>with libunwind (should we? What does it bring us?)
   
   
>
   
   
>Then it's somehow related into how the backtrace handling works in ARM.
   
   
>Anyways, cannot say anything without the core file.
   
   
>
   
   
>Aki
   
   

   
   
Thanks, it took me two hours to produce the core dump, but here it is. I suppose putting it as an attachment is not ok for a mailing list, so I put it on my server instead (tell me if you want it as an attachment instead, I couldn't find that info). See 
https://lepiller.eu/files/core (400KB) and 
https://lepiller.eu/files/test-lib (2.7MB) (the program that dumped core). Thanks for your help!
   
  
  
   
  
  
   Thank you,
  
  
   
  
  
   as I don't have arm at hand, can you provide
  
  
   
  
  
   gdb .test-lib core
  
  
   bt full
  
  
   
  
  
   output?
  
  
   ---
Aki Tuomi
   
 

Re: Test failure on ARM: backtrace_append

[Julien Lepiller]

Le 20 février 2020 13:37:20 GMT-05:00, Aki Tuomi  a 
écrit :
>
>> On 20/02/2020 20:31 Julien Lepiller  wrote:
>> 
>>  
>> Le 20 février 2020 12:58:52 GMT-05:00, Aki Tuomi
> a écrit :
>> >
>> >> On 20/02/2020 18:56 Julien Lepiller  wrote:
>> >> 
>> >>  
>> >> Hi,
>> >> 
>> >> I am a packager in Guix and user of dovecot on an ARM server
>(armhf).
>> >The Guix package fails to build because of a test error (see the
>last
>> >lines of the full build log:
>>
>>https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3).
>> >As the name suggests, this is dovecot 2.3.9.3, the latest version.
>> >Previous versions built fine, as well as the same version on x86 and
>> >x86_64. Note that the build on guix's build farm was done in a qemu
>vm,
>> >but I got the same test failure on real hardware.
>> >> 
>> >> I'm not sure what the best course of action is. Did I find a
>> >legitimate bug, or should I simply ignore that test for that
>> >architecture? Dovecot itself seems to be running fine when I ignore
>the
>> >tests.
>> >> 
>> >> Thanks for any guidance you could provide!
>> >
>> >(sorry for the previous mail, client acted up...)
>> >
>> >Can you provide backtrace for the core file? This seems to be
>related
>> >to libunwind somehow.
>> >
>> >Aki
>> 
>> I can try, but it will take me some time to rebuild. I forgot to keep
>the previous attempts. I think this is unrelated to libunwind since the
>asserts that fail are in the #elif case for libunwind. We don't build
>with libunwind (should we? What does it bring us?)
>
>Then it's somehow related into how the backtrace handling works in ARM.
>Anyways, cannot say anything without the core file.
>
>Aki

Thanks, it took me two hours to produce the core dump, but here it is. I 
suppose putting it as an attachment is not ok for a mailing list, so I put it 
on my server instead (tell me if you want it as an attachment instead, I 
couldn't find that info). See https://lepiller.eu/files/core (400KB) and 
https://lepiller.eu/files/test-lib (2.7MB) (the program that dumped core). 
Thanks for your help!

Re: Test failure on ARM: backtrace_append

[Aki Tuomi]

> On 20/02/2020 20:31 Julien Lepiller  wrote:
> 
>  
> Le 20 février 2020 12:58:52 GMT-05:00, Aki Tuomi  
> a écrit :
> >
> >> On 20/02/2020 18:56 Julien Lepiller  wrote:
> >> 
> >>  
> >> Hi,
> >> 
> >> I am a packager in Guix and user of dovecot on an ARM server (armhf).
> >The Guix package fails to build because of a test error (see the last
> >lines of the full build log:
> >https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3).
> >As the name suggests, this is dovecot 2.3.9.3, the latest version.
> >Previous versions built fine, as well as the same version on x86 and
> >x86_64. Note that the build on guix's build farm was done in a qemu vm,
> >but I got the same test failure on real hardware.
> >> 
> >> I'm not sure what the best course of action is. Did I find a
> >legitimate bug, or should I simply ignore that test for that
> >architecture? Dovecot itself seems to be running fine when I ignore the
> >tests.
> >> 
> >> Thanks for any guidance you could provide!
> >
> >(sorry for the previous mail, client acted up...)
> >
> >Can you provide backtrace for the core file? This seems to be related
> >to libunwind somehow.
> >
> >Aki
> 
> I can try, but it will take me some time to rebuild. I forgot to keep the 
> previous attempts. I think this is unrelated to libunwind since the asserts 
> that fail are in the #elif case for libunwind. We don't build with libunwind 
> (should we? What does it bring us?)

Then it's somehow related into how the backtrace handling works in ARM. 
Anyways, cannot say anything without the core file.

Aki

Re: Test failure on ARM: backtrace_append

[Julien Lepiller]

Le 20 février 2020 12:58:52 GMT-05:00, Aki Tuomi  a 
écrit :
>
>> On 20/02/2020 18:56 Julien Lepiller  wrote:
>> 
>>  
>> Hi,
>> 
>> I am a packager in Guix and user of dovecot on an ARM server (armhf).
>The Guix package fails to build because of a test error (see the last
>lines of the full build log:
>https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3).
>As the name suggests, this is dovecot 2.3.9.3, the latest version.
>Previous versions built fine, as well as the same version on x86 and
>x86_64. Note that the build on guix's build farm was done in a qemu vm,
>but I got the same test failure on real hardware.
>> 
>> I'm not sure what the best course of action is. Did I find a
>legitimate bug, or should I simply ignore that test for that
>architecture? Dovecot itself seems to be running fine when I ignore the
>tests.
>> 
>> Thanks for any guidance you could provide!
>
>(sorry for the previous mail, client acted up...)
>
>Can you provide backtrace for the core file? This seems to be related
>to libunwind somehow.
>
>Aki

I can try, but it will take me some time to rebuild. I forgot to keep the 
previous attempts. I think this is unrelated to libunwind since the asserts 
that fail are in the #elif case for libunwind. We don't build with libunwind 
(should we? What does it bring us?)

Re: Test failure on ARM: backtrace_append

[Aki Tuomi]

> On 20/02/2020 18:56 Julien Lepiller  wrote:
> 
>  
> Hi,
> 
> I am a packager in Guix and user of dovecot on an ARM server (armhf). The 
> Guix package fails to build because of a test error (see the last lines of 
> the full build log: 
> https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3).
>  As the name suggests, this is dovecot 2.3.9.3, the latest version. Previous 
> versions built fine, as well as the same version on x86 and x86_64. Note that 
> the build on guix's build farm was done in a qemu vm, but I got the same test 
> failure on real hardware.
> 
> I'm not sure what the best course of action is. Did I find a legitimate bug, 
> or should I simply ignore that test for that architecture? Dovecot itself 
> seems to be running fine when I ignore the tests.
> 
> Thanks for any guidance you could provide!

(sorry for the previous mail, client acted up...)

Can you provide backtrace for the core file? This seems to be related to 
libunwind somehow.

Aki

Re: Test failure on ARM: backtrace_append

[Aki Tuomi]

> On 20/02/2020 18:56 Julien Lepiller  wrote:
> 
>  
> Hi,
> 
> I am a packager in Guix and user of dovecot on an ARM server (armhf). The 
> Guix package fails to build because of a test error (see the last lines of 
> the full build log: 
> https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3).
>  As the name suggests, this is dovecot 2.3.9.3, the latest version. Previous 
> versions built fine, as well as the same version on x86 and x86_64. Note that 
> the build on guix's build farm was done in a qemu vm, but I got the same test 
> failure on real hardware.
> 
> I'm not sure what the best course of action is. Did I find a legitimate bug, 
> or should I simply ignore that test for that architecture? Dovecot itself 
> seems to be running fine when I ignore the tests.
> 
> Thanks for any guidance you could provide!

Test failure on ARM: backtrace_append

[Julien Lepiller]

Hi,

I am a packager in Guix and user of dovecot on an ARM server (armhf). The Guix 
package fails to build because of a test error (see the last lines of the full 
build log: 
https://ci.guix.gnu.org/log/f5if2qb5rsqag3a6jy5vga1l9hm9pkj0-dovecot-2.3.9.3). 
As the name suggests, this is dovecot 2.3.9.3, the latest version. Previous 
versions built fine, as well as the same version on x86 and x86_64. Note that 
the build on guix's build farm was done in a qemu vm, but I got the same test 
failure on real hardware.

I'm not sure what the best course of action is. Did I find a legitimate bug, or 
should I simply ignore that test for that architecture? Dovecot itself seems to 
be running fine when I ignore the tests.

Thanks for any guidance you could provide!

RE: How to send a test message directly to lmtp, to test proxying

[Marc Roos via dovecot]

 
Thanks! I am now doing it like this 

cat test.msg | /usr/libexec/dovecot/lmtp

[@~]# cat test.msg
MAIL FROM:
RCPT TO:
DATA
Subject: AAA subject 977

This is the message 977 body


. 



-Original Message-
Subject: Re: How to send a test message directly to lmtp, to test 
proxying


On 12.11.2019 15.26, Marc Roos via dovecot wrote:
>
> How to send a test message directly to lmtp, to test proxying? 

Using LMTP protocol:

LHLO localhost

MAIL FROM:

RCPT TO:

DATA

...

.

Aki

Re: How to send a test message directly to lmtp, to test proxying

[Aki Tuomi via dovecot]

On 12.11.2019 15.26, Marc Roos via dovecot wrote:
>
> How to send a test message directly to lmtp, to test proxying? 

Using LMTP protocol:

LHLO localhost

MAIL FROM:

RCPT TO:

DATA

...

.

Aki

How to send a test message directly to lmtp, to test proxying

[Marc Roos via dovecot]

How to send a test message directly to lmtp, to test proxying? 

doveadm 2.2.36-3.el7.x86_64 mailbox list -u test, does not use symlinked mailboxes

[Marc Roos via dovecot]

Maybe this has been already fixed, but symlinked mailboxes are not shown 
by

[@ dovecot]# doveadm mailbox list -u test | sort
Archive
Archive/2018
Archive/2019
Archive/2019old
Archive/Archive
Drafts
INBOX
INBOX/test1
INBOX/test2
INBOX/test3
Junk
Sent
test
testing-folder-home
testing-folder-home/another folder
Trash


dovecot-2.2.36-3.el7.x86_64
CentOS Linux release 7.6.1810 (Core)

Re: 2.3.6 lib-smtp test failure in CentOS 6

[Peter via dovecot]

On 7/05/19 1:20 PM, Peter wrote:
Other than the raw backtrace I left quoted above, unfortunately no. When 
I just tried to build it again it worked, so it's some intermitent build 
issue that I can't re-produce.  I'll try a few more times and see if it 
fails again, though.


I ran the failed test several times in gdb and could not reproduce the 
issue, so I'm letting it go for now.


This calls into question my thinking that it's only a CentOS 6 issue, it 
may very well be an issue on CentOS 7 as well but just not triggered the 
intermittent condition.


It occurs to me that it might also be a corrupted library install since 
I'm building in mock the mock chroot gets re-initialized for each build, 
or even a small possibility that it was a lib that was updated from 
CentOS since the initial failing build.



Peter

Re: 2.3.6 lib-smtp test failure in CentOS 6

[Peter via dovecot]

On 7/05/19 11:08 AM, Stephan Bosch wrote:
CLIENT: Error: Raw backtrace: 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x4547ea] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x454891] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(_start+0) 
[0x4193f8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41fb95] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x4203f0] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x421d77] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(smtp_client_command_input_reply+0x17d) 
[0x42ffdd] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x42145b] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_call_io+0x61) 
[0x461d81] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_handler_run_internal+0xd6) 
[0x463c16] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_handler_run+0x59) 
[0x461e79] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_run+0x38) 
[0x4620a8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41a619] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41aaa8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41ab7d] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x44beae] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(test_run+0x11) 
[0x44c011] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(main+0x115) 
[0x419d65] -> /lib64/libc.so.6(__libc_start_main+0x100) 
[0x7f3850d4ad20] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x419421]


Can you get a GDB backtrace for this?


Other than the raw backtrace I left quoted above, unfortunately no. 
When I just tried to build it again it worked, so it's some intermitent 
build issue that I can't re-produce.  I'll try a few more times and see 
if it fails again, though.


This calls into question my thinking that it's only a CentOS 6 issue, it 
may very well be an issue on CentOS 7 as well but just not triggered the 
intermittent condition.



Peter

Re: 2.3.6 lib-smtp test failure in CentOS 6

[Stephan Bosch via dovecot]

On 02/05/2019 06:52, Peter via dovecot wrote:

After applying the patches in my previous message...

I'm getting the following when building dovecot for CentOS 6 (but not 
for CentOS 7):



lmtp payload - normal: parallel pipelining ssl ... 
: ok
CLIENT: Panic: file smtp-client-connection.c: line 1309 
(smtp_client_connection_established): assertion failed: 
(!conn->connect_succeeded)
CLIENT: Error: Raw backtrace: 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x4547ea] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x454891] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(_start+0) 
[0x4193f8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41fb95] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x4203f0] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x421d77] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(smtp_client_command_input_reply+0x17d) 
[0x42ffdd] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x42145b] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_call_io+0x61) 
[0x461d81] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_handler_run_internal+0xd6) 
[0x463c16] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_handler_run+0x59) 
[0x461e79] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_run+0x38) 
[0x4620a8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41a619] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41aaa8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41ab7d] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x44beae] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(test_run+0x11) 
[0x44c011] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(main+0x115) 
[0x419d65] -> /lib64/libc.so.6(__libc_start_main+0x100) 
[0x7f3850d4ad20] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x419421]

/bin/sh: line 1: 28384 Aborted ./$bin
make[3]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp'

make[3]: *** [check-local] Error 1
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp'

make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.6/src'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.9PlfRJ (%check)


Can you get a GDB backtrace for this?

Regards,

Stephan.

Re: http-lib test failures when building dovecot-2.3.5 and later in mock builder

[Stephan Bosch via dovecot]

On 02/05/2019 22:54, Tuomo Soini via dovecot wrote:

There is random failure in test-http-payload when building rpm package
from 2.3.6. I couldn't reproduce that in normal system but that happens
something like every second try in mock chroot build envirnoment. Other
tests don't have issues so it looks like test is not very reliable.
Building 2.3.4 didn't yet have this issue.

./test-http-payload -D output attached.


Yes, we have seen this before. It is being looked at.

Regards,

Stephan.

Re: 2.3.6 lib-smtp test failure in CentOS 6

[Peter via dovecot]

On 2/05/19 4:52 PM, Peter wrote:

After applying the patches in my previous message...

I'm getting the following when building dovecot for CentOS 6 (but not 
for CentOS 7):


Any ideas on this or my other recent message?


Peter

http-lib test failures when building dovecot-2.3.5 and later in mock builder

[Tuomo Soini via dovecot]

There is random failure in test-http-payload when building rpm package
from 2.3.6. I couldn't reproduce that in normal system but that happens
something like every second try in mock chroot build envirnoment. Other
tests don't have issues so it looks like test is not very reliable.
Building 2.3.4 didn't yet have this issue.

./test-http-payload -D output attached.

-- 
Tuomo Soini 
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>


fail.log.gz
Description: application/gzip

2.3.6 lib-smtp test failure in CentOS 6

[Peter via dovecot]

After applying the patches in my previous message...

I'm getting the following when building dovecot for CentOS 6 (but not 
for CentOS 7):



lmtp payload - normal: parallel pipelining ssl ... : ok
CLIENT: Panic: file smtp-client-connection.c: line 1309 
(smtp_client_connection_established): assertion failed: 
(!conn->connect_succeeded)
CLIENT: Error: Raw backtrace: 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x4547ea] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x454891] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(_start+0) 
[0x4193f8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41fb95] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x4203f0] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x421d77] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(smtp_client_command_input_reply+0x17d) 
[0x42ffdd] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x42145b] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_call_io+0x61) 
[0x461d81] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_handler_run_internal+0xd6) 
[0x463c16] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_handler_run+0x59) 
[0x461e79] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(io_loop_run+0x38) 
[0x4620a8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41a619] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41aaa8] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x41ab7d] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x44beae] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(test_run+0x11) 
[0x44c011] -> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload(main+0x115) 
[0x419d65] -> /lib64/libc.so.6(__libc_start_main+0x100) [0x7f3850d4ad20] 
-> 
/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp/.libs/lt-test-smtp-payload() 
[0x419421]

/bin/sh: line 1: 28384 Aborted ./$bin
make[3]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp'

make[3]: *** [check-local] Error 1
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.6/src/lib-smtp'

make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.6/src'
make: *** [check-recursive] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.9PlfRJ (%check)


Peter

Test SASL authentication via telnet (or similar)

[Alessio Cecchi via dovecot]

Hi,

I'm looking for a way to autenticate my email users via Dovecot SASL TCP 
connections from an external nodejs or python script.


Dovecot configuration is fine, if I set in postfix smtpd_sasl_path = 
inet:127.0.0.1:12345 works fine.


But if a try via "telnet 127.0.0.1 12345" to chat with SASL in dovecot 
log found:


dovecot: auth: Error: Authentication client not compatible with this 
server (mixed old and new binaries?)


What is the right way to chat with SASL via TCP port?

Thanks

--
Alessio Cecchi
Postmaster @ http://www.qboxmail.it
https://www.linkedin.com/in/alessice

Re: lib-master test failure i686

[Eric Broch via dovecot]

Thanks, Aki, the patch worked.

On 2/8/2019 8:21 AM, Aki Tuomi wrote:
Can you try if 
https://github.com/dovecot/core/commit/de42b54aaf165d4f62b45be864dde36bdbbc4276.patch 
helps?


Aki
On 08 February 2019 at 17:14 Eric Broch via dovecot < 
dovecot@dovecot.org <mailto:dovecot@dovecot.org>> wrote:



Any Ideas?

On 2/7/2019 12:13 PM, Eric Broch via dovecot wrote:
>

Hello List,
I've built and checked successfully dovecot and dovecot-pigeonhole on
CentOS 6 x86_64
Immediately below are the successful make check (ok) tests of dovecot
'lib-master' (x86_64).
Below that are the unsuccessful (fails) tests of dovecot 'lib-master'
on i686.
Does anyone have a clue as to why these test would fail on i686?
(x86_64):
Making check in lib-master
make[2]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

make check-local
make[3]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

for bin in test-master-service-settings-cache test-event-stats; do \
if ! ./$bin; then exit 1; fi; \
done
0 / 0 tests failed
no merging parent is NULL 
 : ok
no merging parent sent to stats 
.. : ok
no merging parent timestamp differs 
.. : ok
merge events parent NULL 
. : ok
merge events parent sent to stats 
 : ok
skip empty parents 
... : ok
merge events and skip empty parents 
.. : ok

0 / 7 tests failed
make[3]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make[2]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

>

(i686):
Making check in lib-master
make[2]: Entering directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make  check-local
make[3]: Entering directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
for bin in test-master-service-settings-cache test-event-stats; do \
  if !  ./$bin; then exit 1; fi; \
    done
0 / 0 tests failed
no merging parent is NULL 
: ok
test-event-stats.c:365: Assert failed: compare_test_stats_to(
"EVENT    %lu 1   0   0" " stest-event-stats.c %d"
"   l0  0 ctest2\n", id, l)
no merging parent sent to stats ..
: FAILED
test-event-stats.c:394: Assert failed: compare_test_stats_to(
"BEGIN    %lu 0   1 0   0" " stest-event-stats.c
%d  ctest1\n" "EVENT    %lu 1   1 0" "
stest-event-stats.c %d" "   l1  0 ctest2\n"
"END\t%lu\n", idp, lp, idp, l, idp)
no merging parent timestamp differs ..
: FAILED
merge events parent NULL .
: ok
test-event-stats.c:458: Assert failed: compare_test_stats_to(
"EVENT    %lu 1   0   0" " stest-event-stats.c
%d  l0  0" "    ctest3 ctest2  ctest1  Tkey3" "    10
0   Ikey2   20" "   Skey1   str1\n", id, l)
merge events parent sent to stats 
: FAILED
test-event-stats.c:490: Assert failed: compare_test_stats_to(
"BEGIN    %lu 0   1 0   0" " stest-event-stats.c
%d  ctest1\n" "EVENT    %lu 1       3 0   "
"stest-event-stats.c  %d  l3  0" " ctest2\nEND\t%lu\n", id,
lp, id, l, id)
skip empty parents ...
: FAILED
test-event-stats.c:533: Assert failed: compare_test_stats_to(
"BEGIN    %lu 0   1 0   0" " stest-event-stats.c
%d  ctest1\n" "EVENT    %lu 1   3 0   "
"stest-event-stats.c  %d  l3  0   " "ctest4 ctest5
Tkey3   10  0   Skey4" " str4\nEND\t%lu\n", id, lp, id, l, id)
merge events and skip empty parents ..
: FAILED
5 / 7 tests failed
make[3]: Leaving directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make[3]: *** [check-local] Error 1
make[2]: *** [check-am] Error 2
make[2]: Leaving directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
--
Eric Broch
White Horse Technical Consulting (WHTC)

--
Eric Broch
White Horse Technical Consulting (WHTC)


---
Aki Tuomi


--
Eric Broch
White Horse Technical Consulting (WHTC)

Re: lib-master test failure i686

[Eric Broch via dovecot]

Will do!

On 2/8/2019 8:21 AM, Aki Tuomi via dovecot wrote:
Can you try if 
https://github.com/dovecot/core/commit/de42b54aaf165d4f62b45be864dde36bdbbc4276.patch 
helps?


Aki
On 08 February 2019 at 17:14 Eric Broch via dovecot < 
dovecot@dovecot.org <mailto:dovecot@dovecot.org>> wrote:



Any Ideas?

On 2/7/2019 12:13 PM, Eric Broch via dovecot wrote:
>

Hello List,
I've built and checked successfully dovecot and dovecot-pigeonhole on
CentOS 6 x86_64
Immediately below are the successful make check (ok) tests of dovecot
'lib-master' (x86_64).
Below that are the unsuccessful (fails) tests of dovecot 'lib-master'
on i686.
Does anyone have a clue as to why these test would fail on i686?
(x86_64):
Making check in lib-master
make[2]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

make check-local
make[3]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

for bin in test-master-service-settings-cache test-event-stats; do \
if ! ./$bin; then exit 1; fi; \
done
0 / 0 tests failed
no merging parent is NULL 
 : ok
no merging parent sent to stats 
.. : ok
no merging parent timestamp differs 
.. : ok
merge events parent NULL 
. : ok
merge events parent sent to stats 
 : ok
skip empty parents 
... : ok
merge events and skip empty parents 
.. : ok

0 / 7 tests failed
make[3]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make[2]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

>

(i686):
Making check in lib-master
make[2]: Entering directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make  check-local
make[3]: Entering directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
for bin in test-master-service-settings-cache test-event-stats; do \
  if !  ./$bin; then exit 1; fi; \
    done
0 / 0 tests failed
no merging parent is NULL 
: ok
test-event-stats.c:365: Assert failed: compare_test_stats_to(
"EVENT    %lu 1   0   0" " stest-event-stats.c %d"
"   l0  0 ctest2\n", id, l)
no merging parent sent to stats ..
: FAILED
test-event-stats.c:394: Assert failed: compare_test_stats_to(
"BEGIN    %lu 0   1 0   0" " stest-event-stats.c
%d  ctest1\n" "EVENT    %lu 1   1 0" "
stest-event-stats.c %d" "   l1  0 ctest2\n"
"END\t%lu\n", idp, lp, idp, l, idp)
no merging parent timestamp differs ..
: FAILED
merge events parent NULL .
: ok
test-event-stats.c:458: Assert failed: compare_test_stats_to(
"EVENT    %lu 1   0   0" " stest-event-stats.c
%d  l0  0" "    ctest3 ctest2  ctest1  Tkey3" "    10
0   Ikey2   20" "   Skey1   str1\n", id, l)
merge events parent sent to stats 
: FAILED
test-event-stats.c:490: Assert failed: compare_test_stats_to(
"BEGIN    %lu 0   1 0   0" " stest-event-stats.c
%d  ctest1\n" "EVENT    %lu 1       3 0   "
"stest-event-stats.c  %d  l3  0" " ctest2\nEND\t%lu\n", id,
lp, id, l, id)
skip empty parents ...
: FAILED
test-event-stats.c:533: Assert failed: compare_test_stats_to(
"BEGIN    %lu 0   1 0   0" " stest-event-stats.c
%d  ctest1\n" "EVENT    %lu 1   3 0   "
"stest-event-stats.c  %d  l3  0   " "ctest4 ctest5
Tkey3   10  0   Skey4" " str4\nEND\t%lu\n", id, lp, id, l, id)
merge events and skip empty parents ..
: FAILED
5 / 7 tests failed
make[3]: Leaving directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make[3]: *** [check-local] Error 1
make[2]: *** [check-am] Error 2
make[2]: Leaving directory
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
--
Eric Broch
White Horse Technical Consulting (WHTC)

--
Eric Broch
White Horse Technical Consulting (WHTC)


---
Aki Tuomi


--
Eric Broch
White Horse Technical Consulting (WHTC)

Re: lib-master test failure i686

[Aki Tuomi via dovecot]

 
 
  
   Can you try if https://github.com/dovecot/core/commit/de42b54aaf165d4f62b45be864dde36bdbbc4276.patch helps?
  
  
   
  
  
   Aki
  
  
   
On 08 February 2019 at 17:14 Eric Broch via dovecot <
dovecot@dovecot.org> wrote:
   
   

   
   

   
   
Any Ideas?
   
   

   
   
On 2/7/2019 12:13 PM, Eric Broch via dovecot wrote:
   
   
>
   
   

 Hello List,

   
   

 I've built and checked successfully dovecot and dovecot-pigeonhole on


 CentOS 6 x86_64

   
   

 Immediately below are the successful make check (ok) tests of dovecot


 'lib-master' (x86_64).

   
   

 Below that are the unsuccessful (fails) tests of dovecot 'lib-master'


 on i686.

   
   

 Does anyone have a clue as to why these test would fail on i686?

   
   

 (x86_64):

   
   

 Making check in lib-master


 make[2]: Entering directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


 make check-local


 make[3]: Entering directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


 for bin in test-master-service-settings-cache test-event-stats; do \


 if ! ./$bin; then exit 1; fi; \


 done


 0 / 0 tests failed


 no merging parent is NULL  : ok


 no merging parent sent to stats .. : ok


 no merging parent timestamp differs .. : ok


 merge events parent NULL . : ok


 merge events parent sent to stats  : ok


 skip empty parents ... : ok


 merge events and skip empty parents .. : ok


 0 / 7 tests failed


 make[3]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


 make[2]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

   
   
>
   
   

 (i686):

   
   

 Making check in lib-master


 make[2]: Entering directory


 `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


 make  check-local


 make[3]: Entering directory


 `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


 for bin in test-master-service-settings-cache test-event-stats; do \


   if !  ./$bin; then exit 1; fi; \


     done


 0 / 0 tests failed


 no merging parent is NULL 


 : ok
    
    
 test-event-stats.c:365: Assert failed: compare_test_stats_to(


 "EVENT    %lu 1   0   0" "    stest-event-stats.c %d"


 "   l0  0 ctest2\n", id, l)


 no merging parent sent to stats ..
    

 : FAILED


 test-event-stats.c:394: Assert failed: compare_test_stats_to(


 "BEGIN    %lu 0   1 0   0" "    stest-event-stats.c


 %d  ctest1\n" "EVENT    %lu 1   1   0" "


 stest-event-stats.c %d" "   l1  0   ctest2\n"


 "END\t%lu\n", idp, lp, idp, l, idp)


 no merging parent timestamp differs ..


 : FAILED


 merge events parent NULL .


 : ok


 test-event-stats.c:458: Assert failed: compare_test_stats_to(


 "EVENT    %lu 1   0   0" "    stest-event-stats.c


 %d  l0  0" "    ctest3 ctest2  ctest1  Tkey3" "    10 


 0   Ikey2   20" "   Skey1   str1\n", id, l)


 merge events parent sent to stats 


 : FAILED


 test-event-stats.c:490: Assert failed: compare_test_stats_to(


 "BEGIN    %lu 0   1 0   0" "    stest-event-stats.c


 %d  ctest1\n" "EVENT    %lu 1   3   0   "


 "stest-event-stats.c  %d  l3  0" " ctest2\nEND\t%lu\n", id,


 lp, id, l, id)


 skip empty parents ...


 : FAILED


 test-event-stats.c:533: Assert failed: compare_test_stats_to(


 "BEGIN    %lu 0

Re: lib-master test failure i686

[Eric Broch via dovecot]

Any Ideas?

On 2/7/2019 12:13 PM, Eric Broch via dovecot wrote:


Hello List,

I've built and checked successfully dovecot and dovecot-pigeonhole on 
CentOS 6 x86_64


Immediately below are the successful make check (ok) tests of dovecot 
'lib-master' (x86_64).


Below that are the unsuccessful (fails) tests of dovecot 'lib-master' 
on i686.


Does anyone have a clue as to why these test would fail on i686?

(x86_64):

Making check in lib-master
make[2]: Entering directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make  check-local
make[3]: Entering directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
for bin in test-master-service-settings-cache test-event-stats; do \
  if !  ./$bin; then exit 1; fi; \
done
0 / 0 tests failed
no merging parent is NULL  : ok
no merging parent sent to stats .. : ok
no merging parent timestamp differs .. : ok
merge events parent NULL . : ok
merge events parent sent to stats  : ok
skip empty parents ... : ok
merge events and skip empty parents .. : ok
0 / 7 tests failed
make[3]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make[2]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


(i686):

Making check in lib-master
make[2]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

make  check-local
make[3]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

for bin in test-master-service-settings-cache test-event-stats; do \
  if !  ./$bin; then exit 1; fi; \
    done
0 / 0 tests failed
no merging parent is NULL  
: ok
test-event-stats.c:365: Assert failed: compare_test_stats_to( 
"EVENT    %lu 1   0   0" "    stest-event-stats.c %d" 
"   l0  0 ctest2\n", id, l)
no merging parent sent to stats ...... 
: FAILED
test-event-stats.c:394: Assert failed: compare_test_stats_to( 
"BEGIN    %lu 0   1 0   0" "    stest-event-stats.c 
%d  ctest1\n" "EVENT    %lu 1   1   0" " 
stest-event-stats.c %d" "   l1  0   ctest2\n" 
"END\t%lu\n", idp, lp, idp, l, idp)
no merging parent timestamp differs .. 
: FAILED
merge events parent NULL . 
: ok
test-event-stats.c:458: Assert failed: compare_test_stats_to( 
"EVENT    %lu 1   0   0" "    stest-event-stats.c 
%d  l0  0" "    ctest3 ctest2  ctest1  Tkey3" "    10  
0       Ikey2   20" "   Skey1   str1\n", id, l)
merge events parent sent to stats  
: FAILED
test-event-stats.c:490: Assert failed: compare_test_stats_to( 
"BEGIN    %lu 0   1 0   0" "    stest-event-stats.c 
%d  ctest1\n" "EVENT    %lu 1   3   0   " 
"stest-event-stats.c  %d  l3  0" " ctest2\nEND\t%lu\n", id, 
lp, id, l, id)
skip empty parents ... 
: FAILED
test-event-stats.c:533: Assert failed: compare_test_stats_to( 
"BEGIN    %lu 0   1 0   0" "    stest-event-stats.c 
%d  ctest1\n" "EVENT    %lu 1   3   0   " 
"stest-event-stats.c  %d  l3  0   " "ctest4 ctest5  
Tkey3   10  0   Skey4" " str4\nEND\t%lu\n", id, lp, id, l, id)
merge events and skip empty parents .. 
: FAILED

5 / 7 tests failed
make[3]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

make[3]: *** [check-local] Error 1
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


--
Eric Broch
White Horse Technical Consulting (WHTC)


--
Eric Broch
White Horse Technical Consulting (WHTC)

lib-master test failure i686

[Eric Broch via dovecot]

Hello List,

I've built and checked successfully dovecot and dovecot-pigeonhole on 
CentOS 6 x86_64


Immediately below are the successful make check (ok) tests of dovecot 
'lib-master' (x86_64).


Below that are the unsuccessful (fails) tests of dovecot 'lib-master' on 
i686.


Does anyone have a clue as to why these test would fail on i686?

(x86_64):

Making check in lib-master
make[2]: Entering directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make  check-local
make[3]: Entering directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
for bin in test-master-service-settings-cache test-event-stats; do \
  if !  ./$bin; then exit 1; fi; \
done
0 / 0 tests failed
no merging parent is NULL  : ok
no merging parent sent to stats .. : ok
no merging parent timestamp differs .. : ok
merge events parent NULL . : ok
merge events parent sent to stats  : ok
skip empty parents ... : ok
merge events and skip empty parents .. : ok
0 / 7 tests failed
make[3]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'
make[2]: Leaving directory `/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


(i686):

Making check in lib-master
make[2]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

make  check-local
make[3]: Entering directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

for bin in test-master-service-settings-cache test-event-stats; do \
  if !  ./$bin; then exit 1; fi; \
    done
0 / 0 tests failed
no merging parent is NULL  : ok
test-event-stats.c:365: Assert failed: compare_test_stats_to( "EVENT    
%lu 1   0   0" " stest-event-stats.c %d" "   l0  
0   ctest2\n", id, l)
no merging parent sent to stats ...... : 
FAILED
test-event-stats.c:394: Assert failed: compare_test_stats_to( "BEGIN    
%lu 0   1   0 0" "    stest-event-stats.c %d  
ctest1\n" "EVENT %lu 1   1   0" "    stest-event-stats.c 
%d" " l1  0   ctest2\n" "END\t%lu\n", idp, lp, idp, l, idp)
no merging parent timestamp differs .. : 
FAILED

merge events parent NULL . : ok
test-event-stats.c:458: Assert failed: compare_test_stats_to( "EVENT    
%lu 1   0   0" " stest-event-stats.c %d  l0  0" 
"    ctest3  ctest2 ctest1  Tkey3" "    10  0   Ikey2   20" 
"   Skey1 str1\n", id, l)
merge events parent sent to stats  : 
FAILED
test-event-stats.c:490: Assert failed: compare_test_stats_to( "BEGIN    
%lu 0   1   0 0" "    stest-event-stats.c %d  
ctest1\n" "EVENT %lu 1   3   0   " "stest-event-stats.c  
%d l3  0" "    ctest2\nEND\t%lu\n", id, lp, id, l, id)
skip empty parents ... : 
FAILED
test-event-stats.c:533: Assert failed: compare_test_stats_to( "BEGIN    
%lu 0   1   0 0" "    stest-event-stats.c %d  
ctest1\n" "EVENT %lu 1   3   0   " "stest-event-stats.c  
%d l3  0   " "ctest4   ctest5  Tkey3   10  0 Skey4" 
"    str4\nEND\t%lu\n", id, lp, id, l, id)
merge events and skip empty parents .. : 
FAILED

5 / 7 tests failed
make[3]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'

make[3]: *** [check-local] Error 1
make[2]: *** [check-am] Error 2
make[2]: Leaving directory 
`/builddir/build/BUILD/dovecot-2.3.4/src/lib-master'


--
Eric Broch
White Horse Technical Consulting (WHTC)

Moving messages on test server, dovecot.index.log was locked for x seconds on cephfs

[Marc Roos]

I am getting on a test environment were no users are logging in a 
dovecot.index.log was locked when moving messages with doveadm move -u 
testuser Archive/2012 mailbox INBOX/inbox  BEFORE 2013-01-01.

doveadm(testuser): Warning: Transaction log file 
/var/dovecot/testuser/index/.INBOX.inbox/dovecot.index.log was locked 
for 215 seconds (rotating while syncing)

I have read about how this can be related to default locking fcntl and 
nfs, anyone having this solved with cephfs?
https://www.dovecot.org/list/dovecot/2009-January/036194.html

Re: murmurhash3 test failures on big-endian systems

[Apollon Oikonomopoulos]

On 15:55 Wed 28 Mar , Josef 'Jeff' Sipek wrote:
> Ok, there are two commits:
> 
> 35497604d80090a02619024aeec069b32568e4b4 and 
> 5522b8b3d3ed1a99c3b63bb120216af0bd427403
> 
> Together, they should be identical to the patch I sent the other day plus
> your fixup.  Let me know if you have any problems.

Indeed, there are no differences, but I updated the patch in the package 
to include the commit IDs nevertheless.

Also, dovecot now seems to build fine on all big-endian 
architectures[1].

Thanks again,
Apollon

[1] https://buildd.debian.org/status/package.php?p=dovecot=experimental