> 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 sen
Test
Aki
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
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/
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
r 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
> > serve
9: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 verif
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
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.
) 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
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
> 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
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
... : 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_p
> 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 f
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
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
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
>
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
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
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
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
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
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
> 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 dov
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
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
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
>
> 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 noti
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
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.
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
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:
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
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
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
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
... : 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
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
tches/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
a
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
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
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
ng 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 ve
fx 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
fx 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
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
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
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
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@doveco
@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
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
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
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
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
OpenBSD
Original Message
On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote:
Which distro/OS is this?
Aki
> 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
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
nking 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; bac
L 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.
arkmode.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!
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
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.
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
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
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
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
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 fail
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 &
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
> nei
* 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 do
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-ma
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
:
> 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 a
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
gt;> 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
>(ar
t;> >>
>> >>
>> >> 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
r 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 i
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 er
> 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:
>
> 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:
>
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
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
How to send a test message directly to lmtp, to test proxying?
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
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
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
-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/.l
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
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
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
(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] ->
/build
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
ccessful (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
`/build
l (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/BUIL
uccessful 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 fai
(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
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
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
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
1 - 100 of 279 matches
Mail list logo
