Re: MySQL 8.0: Supported?

2019-01-14 Thread Odhiambo Washington
On Tue, 15 Jan 2019 at 04:57, Larry Rosenman  wrote:

> I got a complaint from a FreeBSD user that they couldn't compile dovecot
> against MySQL 8.0.
>
> Is MySQL 8.0 support with 2.3.4?
>
> they receive:
> checking for mysql_init in -lmysqlclient... no
> configure: error: Can't build with MySQL support: libmysqlclient not
>   found ===>  Script "configure" failed unexpectedly.
> Please report the problem to l...@freebsd.org [maintainer] and attach the
> "/wrkdirs/usr/ports/mail/dovecot/work/dovecot-2.3.4/config.log"
>   including the output of the failure of your make command. Also, it
>   might be a good idea to provide an overview of all packages installed
>   on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea).
> *** Error code 1
>
> thanks!
>

I recently installed FreeBSD-12 and installed MySQL-8.0 and build
dovecot-2.3.4 against it.
Well, I tried to do ldd /usr/local/sbin/dovecot to see what it's build
against, but it shows different
output than what I see when I do the same against my Exim. Maybe it's a gcc
vs clang issue, but

root@gw:/usr/home/wash # uname -msrsv
FreeBSD 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC  amd64
root@gw:/usr/home/wash # mysql --version
mysql  Ver 8.0.12 for FreeBSD12.0 on amd64 (Source distribution)
root@gw:/usr/home/wash # strings /usr/local/sbin/dovecot | grep SQL
SQL drivers: mysql postgresql sqlite

In the output you've given, let's just say the issue is that there is
no libmysqlclient.so.21 in the standard INCLUDE path..

I have just extracted dovecot-2.3.4 into a directory and did:
 ./configure --with-mysql=yes

The output is:

---8<
checking for mysql_config... mysql_config
checking for mysql_init in -lmysqlclient... yes
checking mysql.h usability... yes
checking mysql.h presence... yes
checking for mysql.h... yes
checking for mysql_ssl_set in -lmysqlclient... yes
--8<--
Install prefix . : /usr/local
File offsets ... : 64bit
I/O polling  : kqueue
I/O notifys  : kqueue
SSL  : yes (OpenSSL)
GSSAPI . : no
passdbs  : static passwd passwd-file pam checkpassword sql
CFLAGS . : -std=gnu99 -g -O2 -fstack-protector-strong
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes
-Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2
-Wbad-function-cast -Wno-duplicate-decl-specifier -Wstrict-aliasing=2
 : -shadow -bsdauth -sia -ldap -vpopmail
userdbs  : static prefetch passwd passwd-file checkpassword sql
 : -ldap -vpopmail
*SQL drivers  : mysql*
 : -pgsql -sqlite -cassandra
Full text search : squat
 : -lucene -solr
root@gw:/usr/local/SRC/dovecot-2.3.4 #


So, yes, it's supported!


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)


Re: Dovecot 2.3 no longer accepts ssl_key_password

2019-01-14 Thread Aki Tuomi


On 10.1.2019 6.53, Chris Kiakas wrote:
> Hit a little problem when I upgraded a system from FreeBSD 10.3 to 11.2. I 
> did not receive any errors in the upgrade. The system is running 4 jails and 
> everything seems to work except in Dovecot dovecot-2.3.4_5 where when using 
> the exact same configuration which worked in 10.3 with the same password 
> protected certificate key. (doveconf -n -P shows the correct password.)
>
>
> ssl_ca =  ssl_cert =  ssl_dh =  ssl_key =  ssl_key_password = keypassword
>
> The password works with openssl. Changing the password on the key has no 
> effect. Removing the password on the cert with openssl and running dovecot 
> with the new key works.
>
> I installed on another system and I am experiencing the same results. The 
> issue persists whether I install dovecot from ports or pkg. I can't see where 
> the problem is. It seems that Dovecot is unable to read the key when password 
> protected even though it has the correct password. Has anyone experienced 
> this?
>
>
>
> Chris

Hi!

Thanks for reporting this, we'll look into it.


Aki



Re: Import mailbox from different domain

2019-01-14 Thread Sami Ketola


> On 14 Jan 2019, at 22.47, Sergio Belkin  wrote:
> 
> Hi folks,
> Let's say that I have on dovecot the domain example.net  
> and on MS Exchange example.com .
> I've tried to import a mailbox from MS Exchange to Dovecot but it fails, I've 
> run:
> 
>  dsync -Dv   backup -R  -u joe.doe  imapc:
> 
> dsync(joe@example.net ): Error: 
> imapc(192.168.0.2:993 ): Authentication failed: 
> AUTHENTICATE failed.
> 
> Is there a way to submit different domains both on MS Exchange and Dovecot 
> and to make everyone be happy :)  ?

like -o imapc_user=joe@example.com  
-o imapc_password=joe.does.password?

Sami



MySQL 8.0: Supported?

2019-01-14 Thread Larry Rosenman
I got a complaint from a FreeBSD user that they couldn't compile dovecot
against MySQL 8.0.

Is MySQL 8.0 support with 2.3.4?

they receive:
checking for mysql_init in -lmysqlclient... no
configure: error: Can't build with MySQL support: libmysqlclient not
  found ===>  Script "configure" failed unexpectedly.
Please report the problem to l...@freebsd.org [maintainer] and attach the
"/wrkdirs/usr/ports/mail/dovecot/work/dovecot-2.3.4/config.log"
  including the output of the failure of your make command. Also, it
  might be a good idea to provide an overview of all packages installed
  on your system (e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

thanks!

-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 (c) E-Mail: larry...@gmail.com
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106


Re: Solr - complete setup (update)

2019-01-14 Thread Stephan Bosch




Op 14/01/2019 om 07:44 schreef Joan Moreau via dovecot:


Hi Stephan,

What's up with that ?

Thank you so much



Working on it, somewhat anyway.

BTW, did you see this ? :

"""
$ sudo -u solr /opt/solr/bin/solr create -c dovecot
WARNING: Using _default configset with data driven schema functionality. 
NOT RECOMMENDED for production use.
 To turn off: bin/solr config -c dovecot -p 8983 -action 
set-user-property -property update.autoCreateFields -value false
INFO  - 2019-01-14 23:19:56.831; 
org.apache.solr.util.configuration.SSLCredentialProviderFactory; 
Processing SSL Credential Provider chain: env;sysprop


Created new core 'dovecot'
"""

I'll be trying your steps first, but the mentioned command might at 
least get rid of some of the cruft in the default config file.


Regards,

Stephan.



On 2019-01-05 02:04, Stephan Bosch wrote:


Hi,

Op 04/01/2019 om 05:36 schreef Joan Moreau via dovecot:


Hi

This is the summary of my work with SOLR-Dovecot, in my *quest to 
reproduce the previoulsy excellent work of fts_squat*



@Aki : Based on the time I have spent on this, I would love to see 
you updating the Wiki with those improvements, and adding my name 
somewhere


@All : Hope it helps

I'll be going through the description below soon. I've recently 
independently installed fts-solr from scratch. Although this wasn't a 
flawless effort, I managed to get some basic indexing going. From 
this mail thread I understand that there are quite a few more 
problems than I've seen myself so far. Then again, I didn't perform 
extensive tests with actual searches.


Maybe we can turn all this into a test suite that we can run 
internally here at Dovecot. At the very least, the described Dovecot 
bugs need to be addressed and the wiki needs to be updated.


I'll get back to you.


Regards,

Stephan.





*- Installation:*

-> Create a clean install using the default, (at least in the 
Archlinux package), and do a "sudo -u solr solr create -c dovecot ". 
The config files are then in /opt/solr/server/solr/dovecot/conf and 
datafiles in /opt/solr/server/solr/dovecot/data


-> In /opt/solr/server/solr/dovecot/conf/solrconfig.xml:

 * around line 313, change false to 
true


 * around line 147, set 
2000 (or above)


 * around line 696 : uncomment hdr

 * around line 1127, before class="solr.UUIDUpdateProcessorFactory" name="uuid"/>, add 



 * around line 1161, delete the whole class="solr.AddSchemaFieldsUpdateProcessorFactory" 
name="add-schema-fields">


    * around line 1192, remove the whole 
... />


-> Remove /opt/solr/server/solr/dovecot/conf/managed-schema

-> Change "schema.xml" by the one below to reproduce fts_squat 
behavior  (equivalent to " fts_squat = partial=3 full=25" in 
dovecot.conf) (note : such a huge trouble to replace a single line 
setup, anyway...)


-> Move /opt/solr/server/solr (or the subfolder data) to a partition 
with *space*, ideally ext4 or faster file system (it looks like Solr 
is not considering using a simple mysql database, which would make 
sense to avoid all the fuzz and let it transit to a non-java state, 
but that is another story)


-> Config of dovecot.conf is as below

-> The systemd unit shall specify high ulimit for files and proc 
(see below)


-> Increase the memory available for the JavaVM (I put 12Gb as I 
have quite a space on my server, but you may adapt it as per your 
specs) : in /opt/solr/bin/solr.in.sh, set SOLR_HEAP="12288m"


-> As Solr is complaining a lot, you may consider a filter for it in 
your syslog-ng or journald as it pollutes greatly your audit files


-> (re)Start solr (first) and dovecot by systemctl

-> Launch redindex ( doveadm fts rescan -u  )

-> wait for a big while to let the system re-index all your mail boxes


*- Bugs so far*

-> Line 620 of fts_solr dovecot plugin : the size oof header is 
improperly calculated ("huge header" warning for a simple email, 
which kilss the index of that considered email, so basically MOST 
emails as the calculation is wrong)


-> The UID returned by SOlr is to be considered as a STRING (and 
that is maybe the source of problem of the "out of bound" errors in 
fts_solr dovecot, as "long" is not enough)


-> Java errors : A lot of non sense for me, I am not expert in Java. 
But, with increased memory, it seems not crashing, even if 
complaining quite a lot in the logs





*---SCHEMA.XML in /opt/solr/server/solr/dovecot/conf*



id
autoGeneratePhraseQueries="true" positionIncrementGap="100">



catenateNumbers="1" generateNumberParts="1" splitOnCaseChange="1" 
generateWordParts="1" splitOnNumerics="1" catenateAll="1" 
catenateWords="1" preserveOriginal="1"/>













autoGeneratePhraseQueries="true">




















stored="true"/>




stored="true"/>



stored="true"/>
stored="true"/>




*-- DOVECOT.CONF*

mail_plugins = fts fts_solr

plugin {
plugin = fts fts_solr managesieve sieve

fts = solr
fts_autoindex = yes
fts_enforced = yes
fts_solr = url=http://127.0.0.

Import mailbox from different domain

2019-01-14 Thread Sergio Belkin
Hi folks,
Let's say that I have on dovecot the domain example.net and on MS Exchange
example.com.
I've tried to import a mailbox from MS Exchange to Dovecot but it fails,
I've run:

 dsync -Dv   backup -R  -u joe.doe  imapc:

dsync(joe@example.net): Error: imapc(192.168.0.2:993): Authentication
failed: AUTHENTICATE failed.

Is there a way to submit different domains both on MS Exchange and Dovecot
and to make everyone be happy :)  ?

Thanks in advance
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org


RE: mdbox + zlib performing less than just mdbox

2019-01-14 Thread Marc Roos
 >mdbox format is a cross between mbox and sdbox.
 >
 >The idea is that it keeps up to mdbox_rotate_size sized mbox files 
 >which contain mails. Using zlib here will not help, because zlib is 
 >not applied to the full mdbox file, but individual mails within.
 >
 >Also not sure why you think that adding compression would make things
 >faster? =)
 
atop shows a saturated lvm/disk, some were telling me that enabling
compression would alleviate on the disk io's in exchange of higher cpu
utilization.

 
 >I am not fully sure how cephfs works but you might get better results
 >with sdbox format.
 >

I think the one message / one file, is bad for cephfs storage, as I 
understand ceph creates quite a bit of overhead there.
https://www.mail-archive.com/ceph-users@lists.ceph.com/msg48054.html
 
 >> On 14 January 2019 at 17:30 Marc Roos  
wrote:
 >> 
 >> 
 >> 
 >> I have test environment to determine what would be best settings. I 
have 
 >> been told that enabling zlib compression would be good to save iops 
on 
 >> storage. But doing the test now, I get worse results. 
 >> 
 >> [@test2 ~]# pr -m -t mail04-mdbox-vdb-append-64kb-6.log 
 >> mail04-mdbox-vdb-append-64kb-8.log |less
 >> Logi Sele Appe  Logi Sele Appe
 >> 100% 100% 100%  100% 100% 100%
 >>116   1/  1 116   1/  1
 >>009   1/  1 008   1/  1
 >>007   1/  1 008   1/  1
 >>00   10   1/  1 009   1/  1
 >>007   1/  1 006   1/  1
 >>008   1/  1 008   1/  1
 >>009   1/  1 008   1/  1
 >>00   10   1/  1 008   1/  1
 >>009   1/  1 007   1/  1
 >>00   11   1/  1 007   1/  1
 >>   293 1093 ms/cmd avg 432 1232 ms/cmd avg
 >> Logi Sele Appe  Logi Sele Appe
 >> 100% 100% 100%  100% 100% 100%
 >>00   10   1/  1 009   1/  1
 >>009   1/  1 007   1/  1
 >>00   10   1/  1 007   1/  1
 >>009   1/  1 006   1/  1
 >>00   11   1/  1 008   1/  1
 >>009   1/  1 007   1/  1
 >>008   1/  1 006   1/  1
 >>00   11   1/  1 007   1/  1
 >>009   1/  1 005   1/  1
 >>009   1/  1 009   1/  1
 >>00 1063 ms/cmd avg  00 1413 ms/cmd avg
 >> Logi Sele Appe  Logi Sele Appe
 >> 100% 100% 100%  100% 100% 100%
 >>008   1/  1 008   1/  1
 >>00   10   1/  1 008   1/  1
 >>007   1/  1 008   1/  1
 >>00   10   1/  1 006   1/  1
 >>00   10   1/  1 007   1/  1
 >>00   11   1/  1 008   1/  1
 >>007   1/  1 008   1/  1
 >>00   11   1/  1 006   1/  1
 >>008   1/  1 007   1/  1
 >>00   10   1/  1 008   1/  1
 >>00 1077 ms/cmd avg  00 1382 ms/cmd avg
 >> Logi Sele Appe  Logi Sele Appe
 >> 100% 100% 100%  100% 100% 100%
 >>007   1/  1 006   1/  1
 >>009   1/  1 004   1/  1
 >>006   1/  1 007   1/  1
 >>009   1/  1 007   1/  1
 >>008   1/  1 007   1/  1
 >>00   10   1/  1 005   1/  1
 >>009   1/  1 008   1/  1
 >>007   1/  1 006   1/  1
 >>009   1/  1 006   1/  1
 >>007   1/  1 008   1/  1
 >>00 1246 ms/cmd avg  00 1524 ms/cmd avg
 >> ...
 >> ...
 >> ...
 >> Logi Sele Appe  Logi Sele Appe
 >> 100% 100% 100%  100% 100% 100%
 >>008   1/  1 005   1/  1
 >>006   1/  1 004   1/  1
 >>006   1/  1 004   1/  1
 >>007   1/  1 004   1/  1
 >>005   1/  1 005   1/  1
 >>005   1/  1 004   1/  1
 >>006   1/  1 004   1/  1
 >>0  

Sieve: reject certain mime-types and notify recipient

2019-01-14 Thread Ralf Becker
I have to reject office files for a certain domain plus notifying the
original recipient about the rejection too.

require ["fileinto","reject","body","enotify","variables"];

if allof (address :contains ["To","TO","Cc","CC"] "@example.org", body
:content  "application/msword" :contains "") {
    set "to" "${1}";
    # :matches is used to get the value of the Subject header
    if header :matches "Subject" "*" {
    set "subject" "${1}";
    }
    # :matches is used to get the value of the From header
    if header :matches "From" "*" {
    set "from" "${1}";
    }
    notify :message "Rejected Office Datei ${from}: ${subject}" "${to}";
    reject text:
Aus Sicherheitsgründen nehmen wir keine Office Dateien mehr an. Bitte
senden Sie uns ein PDF.
.
;
}

A manual sievec call gives not error and if I remove everything but the
reject line it works.

Any ideas?

-- 

Ralf Becker
EGroupware GmbH [www.egroupware.org]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 631 31657-0



signature.asc
Description: OpenPGP digital signature


Re: [FTS Xapian] Beta release

2019-01-14 Thread Joan Moreau via dovecot

It is indeed better is you use the issue tracker of github:
https://github.com/grosjo/fts-xapian/issues 

I updated the Readme accordingly 


On 2019-01-14 14:24, Stephan Bosch wrote:

Op 14-1-2019 om 13:40 schreef Aki Tuomi: 


Just to remind that now that there is a github repo for fts-xapian, you could 
maybe open these issues there instead?

Although README.md currently says:

"Please feel free to send your questions, together with the dovecot log file, to j...@grosjo.net 
 or to the dovecot ML dovecot@dovecot.org 
."

Regards,

Stephan.

Aki

On 14.1.2019 14.29, Odhiambo Washington wrote: Testing a compile on FreeBSD.

gmake[2]: Entering directory '/usr/home/wash/Tools/Dovecot/fts-xapian/src'
/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I. -I.. 
-I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot  -g -O2 
-MT fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o 
fts-backend-xapian.lo fts-backend-xapian.cpp
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I.. 
-I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot -g -O2 -MT 
fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c 
fts-backend-xapian.cpp  -fPIC -DPIC -o .libs/fts-backend-xapian.o
fts-backend-xapian.cpp:3:10: fatal error: 'xapian.h' file not found
#include 
^~

Well, I installed xapian-core and the xapian.h is in /usr/local/include/

I can overcome the fatal error by doing:

env CPPFLAGS=-I/usr/local/include PANDOC=false ./configure --prefix=/opt 
--with-dovecot=/opt/dovecot2.3/lib/dovecot/

Is that something that you can address within the code or we (*BSD) have to 
live with it?

During `make`, the following warning is generated:

/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I. -I.. 
-I/opt/dovecot2.3/include/dovecot  -I/usr/local/include 
-I/opt/dovecot2.3/include/dovecot  -g -O2 -MT fts-backend-xapian.lo -MD -MP 
-MF .deps/fts-backend-xapian.Tpo -c -o fts-backend-xapian.lo 
fts-backend-xapian.cpp
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I.. 
-I/opt/dovecot2.3/include/dovecot -I/usr/local/include 
-I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo -MD -MP -MF 
.deps/fts-backend-xapian.Tpo -c fts-backend-xapian.cpp  -fPIC -DPIC -o 
.libs/fts-backend-xapian.o
fts-backend-xapian.cpp:486:14: warning: format string is not a string literal 
(potentially insecure) [-Wformat-security]
i_warning(e.get_msg().c_str());
^~~
fts-backend-xapian.cpp:486:14: note: treat the string as an argument to avoid 
this
i_warning(e.get_msg().c_str());
^
"%s",
1 warning generated.

Is that something you can look into as well?

On Mon, 14 Jan 2019 at 11:43, Joan Moreau mailto:j...@grosjo.net>> wrote:

THank you Odhiambo. I updated accordingly

On 2019-01-14 08:07, Odhiambo Washington wrote:

In your README.md, perhaps "This project intends to provide a
straightforward and simple *procedure *to configure FTS plugin
for Dovecot, leveraging the efforts by the Xapian.org team." is
better??
Also in the part after cloning from git:
./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This
/path/to/dovecot is not obvious. Is it the dovecot binary or what??]

On Mon, 14 Jan 2019 at 09:42, Joan Moreau via dovecot
mailto:dovecot@dovecot.org>> wrote:

Thank you Stephan.

The version here shall be up and running :
https://github.com/grosjo/fts-xapian

On 2019-01-14 00:07, Stephan Bosch wrote:

Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot:

I tried to combined it, the "autoreconf" errors are solved

Now, when I type "make install", the lib is not
pushed into dovecot folder, but somewhere in
/usr/local/...

How to adjust this to have it arriving in the proper folder ?

Depends on your system. It mostly a matter of setting a
proper --prefix directory for configure, but other paths
are configurable as well. I usually check what the
official distribution package for Dovecot is doing and
use that as a basis.

For Debian I use the following configure command:

./configure --with-ldap=plugin --with-ssl=openssl
--with-sql=plugin --with-lua=plugin --with-pgsql
--with-mysql --with-sqlite \
--with-gssapi=plugin --with-solr
--with-ioloop=best --enable-maintainer-mode \
--prefix=/usr --sysconfdir=/etc
--libexecdir=/usr/lib --localstatedir=/var
--mandir=/usr/share/man \
--infodir=/usr/share/info
--with-moduledir=/usr/lib/dovecot/modules
--disable-rpath --disable-static

Regards,

Stephan

On 2019-01-13 21:01, Tuomi, Aki wrote:

You copied your Makefile.am there. Stephan made
you a working version, can you try that?
(sorry for dup)
Aki
 Original message 
From: Joan Moreau mailto:j...@grosjo.net>>
Date: 13/01/2019 21:39 (GMT+02:00)
To: Stephan Bosch mailto:step...@rename-it.nl>>
Cc: Aki Tuomi mailto:aki.tu...@open-xchange.com>>
Subject: Re: [FTS Xapian] Beta release

I used the skeleton from Aki :
https://github.com/grosjo/fts-xapian

However, when I try to act

Re: [FTS Xapian] Beta release

2019-01-14 Thread Joan Moreau via dovecot

It is indeed better is you use the issue tracker of github:
https://github.com/grosjo/fts-xapian/issues 

I updated the Readme accordingly 


On 2019-01-14 14:24, Stephan Bosch wrote:

Op 14-1-2019 om 13:40 schreef Aki Tuomi: 


Just to remind that now that there is a github repo for fts-xapian, you could 
maybe open these issues there instead?

Although README.md currently says:

"Please feel free to send your questions, together with the dovecot log file, to j...@grosjo.net 
 or to the dovecot ML dovecot@dovecot.org 
."

Regards,

Stephan.

Re: mdbox + zlib performing less than just mdbox

2019-01-14 Thread Aki Tuomi
mdbox format is a cross between mbox and sdbox.

The idea is that it keeps up to mdbox_rotate_size sized mbox files which 
contain mails. Using zlib here will not help, because zlib is not applied to 
the full mdbox file, but individual mails within.

Also not sure why you think that adding compression would make things faster? =)

I am not fully sure how cephfs works but you might get better results with 
sdbox format.

Aki

> On 14 January 2019 at 17:30 Marc Roos  wrote:
> 
> 
> 
> I have test environment to determine what would be best settings. I have 
> been told that enabling zlib compression would be good to save iops on 
> storage. But doing the test now, I get worse results. 
> 
> [@test2 ~]# pr -m -t mail04-mdbox-vdb-append-64kb-6.log 
> mail04-mdbox-vdb-append-64kb-8.log |less
> Logi Sele Appe  Logi Sele Appe
> 100% 100% 100%  100% 100% 100%
>116   1/  1 116   1/  1
>009   1/  1 008   1/  1
>007   1/  1 008   1/  1
>00   10   1/  1 009   1/  1
>007   1/  1 006   1/  1
>008   1/  1 008   1/  1
>009   1/  1 008   1/  1
>00   10   1/  1 008   1/  1
>009   1/  1 007   1/  1
>00   11   1/  1 007   1/  1
>   293 1093 ms/cmd avg 432 1232 ms/cmd avg
> Logi Sele Appe  Logi Sele Appe
> 100% 100% 100%  100% 100% 100%
>00   10   1/  1 009   1/  1
>009   1/  1 007   1/  1
>00   10   1/  1 007   1/  1
>009   1/  1 006   1/  1
>00   11   1/  1 008   1/  1
>009   1/  1 007   1/  1
>008   1/  1 006   1/  1
>00   11   1/  1 007   1/  1
>009   1/  1 005   1/  1
>009   1/  1 009   1/  1
>00 1063 ms/cmd avg  00 1413 ms/cmd avg
> Logi Sele Appe  Logi Sele Appe
> 100% 100% 100%  100% 100% 100%
>008   1/  1 008   1/  1
>00   10   1/  1 008   1/  1
>007   1/  1 008   1/  1
>00   10   1/  1 006   1/  1
>00   10   1/  1 007   1/  1
>00   11   1/  1 008   1/  1
>007   1/  1 008   1/  1
>00   11   1/  1 006   1/  1
>008   1/  1 007   1/  1
>00   10   1/  1 008   1/  1
>00 1077 ms/cmd avg  00 1382 ms/cmd avg
> Logi Sele Appe  Logi Sele Appe
> 100% 100% 100%  100% 100% 100%
>007   1/  1 006   1/  1
>009   1/  1 004   1/  1
>006   1/  1 007   1/  1
>009   1/  1 007   1/  1
>008   1/  1 007   1/  1
>00   10   1/  1 005   1/  1
>009   1/  1 008   1/  1
>007   1/  1 006   1/  1
>009   1/  1 006   1/  1
>007   1/  1 008   1/  1
>00 1246 ms/cmd avg  00 1524 ms/cmd avg
> ...
> ...
> ...
> Logi Sele Appe  Logi Sele Appe
> 100% 100% 100%  100% 100% 100%
>008   1/  1 005   1/  1
>006   1/  1 004   1/  1
>006   1/  1 004   1/  1
>007   1/  1 004   1/  1
>005   1/  1 005   1/  1
>005   1/  1 004   1/  1
>006   1/  1 004   1/  1
>007   1/  1 005   1/  1
>006   1/  1 004   1/  1
>007   1/  1 005   1/  1
>00 1596 ms/cmd avg  00 2308 ms/cmd avg
> Logi Sele Appe  Logi Sele Appe
> 100% 100% 100%  100% 100% 100%
>007   1/  1 004   1/  1
>00 1583 ms/cmd avg  004   1/  1
>00 2331 m

mdbox + zlib performing less than just mdbox

2019-01-14 Thread Marc Roos


I have test environment to determine what would be best settings. I have 
been told that enabling zlib compression would be good to save iops on 
storage. But doing the test now, I get worse results. 

[@test2 ~]# pr -m -t mail04-mdbox-vdb-append-64kb-6.log 
mail04-mdbox-vdb-append-64kb-8.log |less
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   116   1/  1 116   1/  1
   009   1/  1 008   1/  1
   007   1/  1 008   1/  1
   00   10   1/  1 009   1/  1
   007   1/  1 006   1/  1
   008   1/  1 008   1/  1
   009   1/  1 008   1/  1
   00   10   1/  1 008   1/  1
   009   1/  1 007   1/  1
   00   11   1/  1 007   1/  1
  293 1093 ms/cmd avg 432 1232 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   00   10   1/  1 009   1/  1
   009   1/  1 007   1/  1
   00   10   1/  1 007   1/  1
   009   1/  1 006   1/  1
   00   11   1/  1 008   1/  1
   009   1/  1 007   1/  1
   008   1/  1 006   1/  1
   00   11   1/  1 007   1/  1
   009   1/  1 005   1/  1
   009   1/  1 009   1/  1
   00 1063 ms/cmd avg  00 1413 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   008   1/  1 008   1/  1
   00   10   1/  1 008   1/  1
   007   1/  1 008   1/  1
   00   10   1/  1 006   1/  1
   00   10   1/  1 007   1/  1
   00   11   1/  1 008   1/  1
   007   1/  1 008   1/  1
   00   11   1/  1 006   1/  1
   008   1/  1 007   1/  1
   00   10   1/  1 008   1/  1
   00 1077 ms/cmd avg  00 1382 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   007   1/  1 006   1/  1
   009   1/  1 004   1/  1
   006   1/  1 007   1/  1
   009   1/  1 007   1/  1
   008   1/  1 007   1/  1
   00   10   1/  1 005   1/  1
   009   1/  1 008   1/  1
   007   1/  1 006   1/  1
   009   1/  1 006   1/  1
   007   1/  1 008   1/  1
   00 1246 ms/cmd avg  00 1524 ms/cmd avg
...
...
...
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   008   1/  1 005   1/  1
   006   1/  1 004   1/  1
   006   1/  1 004   1/  1
   007   1/  1 004   1/  1
   005   1/  1 005   1/  1
   005   1/  1 004   1/  1
   006   1/  1 004   1/  1
   007   1/  1 005   1/  1
   006   1/  1 004   1/  1
   007   1/  1 005   1/  1
   00 1596 ms/cmd avg  00 2308 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   007   1/  1 004   1/  1
   00 1583 ms/cmd avg  004   1/  1
   00 2331 ms/cmd avg
Totals:
Logi Sele Appe  Totals:
100% 100% 100%  Logi Sele Appe
   11 1978  100% 100% 100%
   11 1145









Re: Error: User b...@aaa.bbb doesn't have home dir set, disabling duplicate database

2019-01-14 Thread subscription1
Have enabled debug as suggested, but don't really know what I'm looking 
for or what the 'correct' output should be.


-

Jan 14 15:06:03 master: Info: Dovecot v2.2.33.2 (d6601f4ec) starting up 
for imap, lmtp, sieve (core dumps disabled)
Jan 14 15:07:09 auth: Debug: Loading modules from directory: 
/usr/lib/dovecot/modules/auth
Jan 14 15:07:09 auth: Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/lib20_auth_var_expand_crypt.so
Jan 14 15:07:09 auth: Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/libdriver_mysql.so
Jan 14 15:07:09 auth: Debug: Read auth token secret from 
/var/run/dovecot/auth-token-secret.dat

Jan 14 15:07:09 auth: Debug: auth client connected (pid=5343)
Jan 14 15:07:10 auth: Debug: client in: AUTH    1    PLAIN 
service=imap    secured    session=MpKNj2t/V7XV4SEm 
lip=173.212.231.229    rip=213.225.33.38    lport=993 rport=46423    
local_name=imap.mydomain.com

Jan 14 15:07:10 auth: Debug: client passdb out: CONT    1
Jan 14 15:07:10 auth: Debug: client in: CONT
Jan 14 15:07:10 auth-worker(5346): Debug: Loading modules from 
directory: /usr/lib/dovecot/modules/auth
Jan 14 15:07:10 auth-worker(5346): Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/lib20_auth_var_expand_crypt.so
Jan 14 15:07:10 auth-worker(5346): Debug: Module loaded: 
/usr/lib/dovecot/modules/auth/libdriver_mysql.so
Jan 14 15:07:10 auth-worker(5346): Debug: 
sql(mailus...@mydomain.com,213.225.33.38,): query: 
SELECT username AS user, domain, password FROM accounts WHERE username = 
'mailuser1' AND domain = 'mydomain.com' and enabled = true;
Jan 14 15:07:10 auth-worker(5346): Debug: 
sql(mailus...@mydomain.com,213.225.33.38,): username 
changed mailus...@mydomain.com -> mailuser1
Jan 14 15:07:10 auth-worker(5346): Debug: 
sql(mailuser1,213.225.33.38,): username changed 
mailuser1 -> mailus...@mydomain.com
Jan 14 15:07:10 auth: Debug: 
sql(mailus...@mydomain.com,213.225.33.38,): username 
changed mailus...@mydomain.com -> mailuser1
Jan 14 15:07:10 auth: Debug: 
sql(mailuser1,213.225.33.38,): username changed 
mailuser1 -> mailus...@mydomain.com
Jan 14 15:07:10 auth: Debug: client passdb out: OK    1 
user=mailus...@mydomain.com
Jan 14 15:07:10 auth: Debug: master in: REQUEST    1124466689 5343    
1    f6508d0565d31959337b995fee8c8fc0 session_pid=5347    request_auth_token
Jan 14 15:07:10 auth-worker(5346): Debug: 
passwd(mailus...@mydomain.com,213.225.33.38,): lookup
Jan 14 15:07:10 auth-worker(5346): Info: 
passwd(mailus...@mydomain.com,213.225.33.38,): unknown 
user
Jan 14 15:07:10 auth-worker(5346): Debug: 
sql(mailus...@mydomain.com,213.225.33.38,): SELECT 
concat('*:storage=', quota, 'M') AS quota_rule FROM accounts WHERE 
username = 'mailuser1' AND domain = 'mydomain.com' AND sendonly = false;
Jan 14 15:07:10 auth: Debug: master userdb out: USER 1124466689    
mailus...@mydomain.com quota_rule=*:storage=2048M 
auth_token=c0af49e6da382961494c74d54add28b3a077f23c
Jan 14 15:07:10 imap-login: Info: Login: user=, 
method=PLAIN, rip=213.225.33.38, lip=173.212.231.229, mpid=5347, TLS, 
session=
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Loading modules 
from directory: /usr/lib/dovecot/modules
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Module loaded: 
/usr/lib/dovecot/modules/lib10_quota_plugin.so
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Module loaded: 
/usr/lib/dovecot/modules/lib11_imap_quota_plugin.so
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Module loaded: 
/usr/lib/dovecot/modules/lib15_notify_plugin.so
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Module loaded: 
/usr/lib/dovecot/modules/lib20_replication_plugin.so
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Module loaded: 
/usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Added userdb 
setting: plugin/quota_rule=*:storage=2048M
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Effective uid=1001, 
gid=1001, home=
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: quota: No quota 
setting - plugin disabled
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: replication: No 
mail_replica setting - replication disabled
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Namespace inbox: 
type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, 
subscriptions=yes 
location=maildir:/home/vmail/mailboxes/mydomain.com/mailuser1Jan 14 
15:07:10 imap(mailus...@mydomain.com): Debug: maildir++: 
root=/home/vmail/mailboxes/mydomain.com/mailuser1, index=, indexpvt=, 
control=, inbox=/home/vmail/mailboxes/mydomain.com/mailuser1, alt=
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: Sent: Mailbox 
opened because: append
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: imapsieve: mailbox 
Sent: APPEND event
Jan 14 15:07:10 imap(mailus...@mydomain.com): Error: User 
mailus...@mydomain.com doesn't have home dir set, disabling duplicate 
database
Jan 14 15:07:10 imap(mailus...@mydomain.com): Debug: sieve: Pigeonhole 
ve

What does the mdbox_rotate_size influence?

2019-01-14 Thread Marc Roos


I wondered why mdbox_rotate_size is 2MB by default.

I thought if I increased it to 16MB, maybe there would be less disk io, 
but I dont see any difference. Furthermore I read in some thread that 
increasing it from 2MB, could give problems when deleting messages, can 
someone explain this?

Does anyone have this on a cephfs mount, does it make sense to set this 
to 4MB?


[@test2 ~]# pr -m -t mail04-mdbox-vdb-append-64kb-4MB-6.log 
mail04-mdbox-vdb-append-64kb-16MB-7.log |less
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   116   1/  1 118   1/  1
   009   1/  1 009   1/  1
   007   1/  1 007   1/  1
   00   10   1/  1 008   1/  1
   007   1/  1 00   10   1/  1
   008   1/  1 009   1/  1
   009   1/  1 00   10   1/  1
   00   10   1/  1 009   1/  1
   009   1/  1 007   1/  1
   00   11   1/  1 008   1/  1
  293 1093 ms/cmd avg 371 1110 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   00   10   1/  1 008   1/  1
   009   1/  1 008   1/  1
   00   10   1/  1 00   10   1/  1
   009   1/  1 00   10   1/  1
   00   11   1/  1 008   1/  1
   009   1/  1 009   1/  1
   008   1/  1 006   1/  1
   00   11   1/  1 009   1/  1
   009   1/  1 007   1/  1
   009   1/  1 009   1/  1
   00 1063 ms/cmd avg  00 1202 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   008   1/  1 008   1/  1
   00   10   1/  1 00   10   1/  1
   007   1/  1 00   11   1/  1
   00   10   1/  1 00   10   1/  1
   00   10   1/  1 00   10   1/  1
   00   11   1/  1 009   1/  1
   007   1/  1 008   1/  1
   00   11   1/  1 009   1/  1
   008   1/  1 00   10   1/  1
   00   10   1/  1 007   1/  1
   00 1077 ms/cmd avg  00 1060 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   007   1/  1 009   1/  1
   009   1/  1 00   10   1/  1
   006   1/  1 006   1/  1
   009   1/  1 007   1/  1
   008   1/  1 009   1/  1
   00   10   1/  1 00   10   1/  1
   009   1/  1 009   1/  1
   007   1/  1 00   10   1/  1
   009   1/  1 009   1/  1
   007   1/  1 009   1/  1
   00 1246 ms/cmd avg  00 1138 ms/cmd avg
...
...
...
...
   008   1/  1 009   1/  1
   006   1/  1 008   1/  1
   006   1/  1 007   1/  1
   007   1/  1 008   1/  1
   005   1/  1 009   1/  1
   005   1/  1 00   10   1/  1
   006   1/  1 00   11   1/  1
   007   1/  1 009   1/  1
   006   1/  1 009   1/  1
   007   1/  1 00   10   1/  1
   00 1596 ms/cmd avg  00 1126 ms/cmd avg
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   007   1/  1 008   1/  1
   00 1583 ms/cmd avg  00 1140 ms/cmd avg

Totals: Totals:
Logi Sele Appe  Logi Sele Appe
100% 100% 100%  100% 100% 100%
   11 1978 11 2021





Re: [FTS Xapian] Beta release

2019-01-14 Thread Stephan Bosch



Op 14-1-2019 om 13:40 schreef Aki Tuomi:


Just to remind that now that there is a github repo for fts-xapian, 
you could maybe open these issues there instead?



Although README.md currently says:

"Please feel free to send your questions, together with the dovecot log 
file, to j...@grosjo.net  or to the dovecot ML 
dovecot@dovecot.org ."



Regards,

Stephan.



Aki

On 14.1.2019 14.29, Odhiambo Washington wrote:

Testing a compile on FreeBSD.

gmake[2]: Entering directory 
'/usr/home/wash/Tools/Dovecot/fts-xapian/src'
/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H 
-I. -I.. -I/opt/dovecot2.3/include/dovecot 
-I/opt/dovecot2.3/include/dovecot      -g -O2 -MT 
fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o 
fts-backend-xapian.lo fts-backend-xapian.cpp
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I.. 
-I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot 
-g -O2 -MT fts-backend-xapian.lo -MD -MP -MF 
.deps/fts-backend-xapian.Tpo -c fts-backend-xapian.cpp  -fPIC -DPIC 
-o .libs/fts-backend-xapian.o

fts-backend-xapian.cpp:3:10: fatal error: 'xapian.h' file not found
#include 
         ^~

Well, I installed xapian-core and the xapian.h is in /usr/local/include/

I can overcome the fatal error by doing:

 env CPPFLAGS=-I/usr/local/include PANDOC=false ./configure 
--prefix=/opt --with-dovecot=/opt/dovecot2.3/lib/dovecot/


Is that something that you can address within the code or we (*BSD) 
have to live with it?


During `make`, the following warning is generated:

/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H 
-I. -I.. -I/opt/dovecot2.3/include/dovecot  -I/usr/local/include 
-I/opt/dovecot2.3/include/dovecot      -g -O2 -MT 
fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o 
fts-backend-xapian.lo fts-backend-xapian.cpp
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I.. 
-I/opt/dovecot2.3/include/dovecot -I/usr/local/include 
-I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo 
-MD -MP -MF .deps/fts-backend-xapian.Tpo -c fts-backend-xapian.cpp  
-fPIC -DPIC -o .libs/fts-backend-xapian.o
fts-backend-xapian.cpp:486:14: warning: format string is not a string 
literal (potentially insecure) [-Wformat-security]

i_warning(e.get_msg().c_str());
^~~
fts-backend-xapian.cpp:486:14: note: treat the string as an argument 
to avoid this

i_warning(e.get_msg().c_str());
                                  ^
                                  "%s",
1 warning generated.


Is that something you can look into as well?



On Mon, 14 Jan 2019 at 11:43, Joan Moreau > wrote:


THank you Odhiambo. I updated accordingly



On 2019-01-14 08:07, Odhiambo Washington wrote:


In your README.md, perhaps "This project intends to provide a
straightforward and simple *procedure *to configure FTS plugin
for Dovecot, leveraging the efforts by the Xapian.org team." is
better??
Also in the part after cloning from git:
./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This
/path/to/dovecot is not obvious. Is it the dovecot binary or what??]

On Mon, 14 Jan 2019 at 09:42, Joan Moreau via dovecot
mailto:dovecot@dovecot.org>> wrote:

Thank you Stephan.

The version here shall be up and running :
https://github.com/grosjo/fts-xapian



On 2019-01-14 00:07, Stephan Bosch wrote:



Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot:


I tried to combined it, the "autoreconf" errors are solved

Now, when I type "make install", the lib is not
pushed into dovecot folder, but somewhere in
/usr/local/...

How to adjust this to have it arriving in the proper folder ?


Depends on your system. It mostly a matter of setting a
proper --prefix directory for configure, but other paths
are configurable as well. I usually check what the
official distribution package for Dovecot is doing and
use that as a basis.

For Debian I use the following configure command:

./configure --with-ldap=plugin --with-ssl=openssl
--with-sql=plugin --with-lua=plugin --with-pgsql
--with-mysql --with-sqlite \
    --with-gssapi=plugin --with-solr
--with-ioloop=best --enable-maintainer-mode \
    --prefix=/usr --sysconfdir=/etc
--libexecdir=/usr/lib --localstatedir=/var
--mandir=/usr/share/man \
    --infodir=/usr/share/info
--with-moduledir=/usr/lib/dovecot/modules
--disable-rpath --disable-static

Regards,

Stephan


On 2019-01-13 21:01, Tuomi, Aki wrote:

You copied your Makefile.am there. Stephan made
you a w

Re: [FTS Xapian] Beta release

2019-01-14 Thread Stephan Bosch



Op 14-1-2019 om 13:29 schreef Odhiambo Washington:

Testing a compile on FreeBSD.

[...]


During `make`, the following warning is generated:

/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I. 
-I.. -I/opt/dovecot2.3/include/dovecot  -I/usr/local/include 
-I/opt/dovecot2.3/include/dovecot      -g -O2 -MT 
fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o 
fts-backend-xapian.lo fts-backend-xapian.cpp
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I.. 
-I/opt/dovecot2.3/include/dovecot -I/usr/local/include 
-I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo -MD 
-MP -MF .deps/fts-backend-xapian.Tpo -c fts-backend-xapian.cpp  -fPIC 
-DPIC -o .libs/fts-backend-xapian.o
fts-backend-xapian.cpp:486:14: warning: format string is not a string 
literal (potentially insecure) [-Wformat-security]

i_warning(e.get_msg().c_str());
^~~
fts-backend-xapian.cpp:486:14: note: treat the string as an argument 
to avoid this

i_warning(e.get_msg().c_str());
                                  ^
                                  "%s",
1 warning generated.


-> i_warning("%s", e.get_msg().c_str());


Regards,

Stephan.



Re: [FTS Xapian] Beta release

2019-01-14 Thread Paul Hecker via dovecot
Hi Joan,

opened an issue here:

>

But no, this does not fix the crash, sorry.

Thanks,
Paul

> On 14. Jan 2019, at 13:58, Joan Moreau via dovecot  
> wrote:
> 
> THanks Paul
> 
> Can you try indexing the same emails with "full=10" for instance in the 
> dovecot.conf ?
> 



smime.p7s
Description: S/MIME cryptographic signature


Re: [FTS Xapian] Beta release

2019-01-14 Thread Joan Moreau via dovecot
THanks Paul 


Can you try indexing the same emails with "full=10" for instance in the
dovecot.conf ? 


On 2019-01-14 12:19, Paul Hecker via dovecot wrote:


Thank you. Here is the stack trace with all debug symbols:

On 14. Jan 2019, at 11:07, Stephan Bosch  wrote:

Op 14-1-2019 om 10:55 schreef Paul Hecker via dovecot: OK, got it (my fault, as 
always, put the LimitCORE in the wrong line). Here is the stack trace:

If you want to get rid of those "??" stack trace elements, you'll need to 
install debug symbols for the xapian library. It depends on your system how to do that 
(usually some separate package).

Regards,

Stephan.

On 14. Jan 2019, at 10:33, Joan Moreau via dovecot mailto:dovecot@dovecot.org>> wrote:

Difficult to figure out without a coredump + gdb

I have also battled quite a lot to make sure dovecot can core dump on my 
Archlinux servers.

I remember that the key point was putting*fs.suid_dumpable=2* in /etc/sysctl.d/ 
conf files, *LimitCORE=infinity* in 
/etc/systemd/system/multi-user.target.wants/dovecot.service,  and rebooting the 
server.

My own coredumps are on /var/lib/systemd/coredump/

Re: [FTS Xapian] Beta release

2019-01-14 Thread Aki Tuomi
Just to remind that now that there is a github repo for fts-xapian, you
could maybe open these issues there instead?

Aki

On 14.1.2019 14.29, Odhiambo Washington wrote:
> Testing a compile on FreeBSD.
>
> gmake[2]: Entering directory '/usr/home/wash/Tools/Dovecot/fts-xapian/src'
> /bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
> -I..  -I/opt/dovecot2.3/include/dovecot     
> -I/opt/dovecot2.3/include/dovecot      -g -O2 -MT
> fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o
> fts-backend-xapian.lo fts-backend-xapian.cpp
> libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I..
> -I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot -g
> -O2 -MT fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo
> -c fts-backend-xapian.cpp  -fPIC -DPIC -o .libs/fts-backend-xapian.o
> fts-backend-xapian.cpp:3:10: fatal error: 'xapian.h' file not found
> #include 
>          ^~
>
> Well, I installed xapian-core and the xapian.h is in /usr/local/include/
>
> I can overcome the fatal error by doing:
>
>  env CPPFLAGS=-I/usr/local/include PANDOC=false ./configure
> --prefix=/opt --with-dovecot=/opt/dovecot2.3/lib/dovecot/
>
> Is that something that you can address within the code or we (*BSD)
> have to live with it?
>
> During `make`, the following warning is generated:
>
> /bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
> -I..  -I/opt/dovecot2.3/include/dovecot     -I/usr/local/include
> -I/opt/dovecot2.3/include/dovecot      -g -O2 -MT
> fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c -o
> fts-backend-xapian.lo fts-backend-xapian.cpp
> libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I..
> -I/opt/dovecot2.3/include/dovecot -I/usr/local/include
> -I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo -MD
> -MP -MF .deps/fts-backend-xapian.Tpo -c fts-backend-xapian.cpp  -fPIC
> -DPIC -o .libs/fts-backend-xapian.o
> fts-backend-xapian.cpp:486:14: warning: format string is not a string
> literal (potentially insecure) [-Wformat-security]
>                         i_warning(e.get_msg().c_str());
>                                   ^~~
> fts-backend-xapian.cpp:486:14: note: treat the string as an argument
> to avoid this
>                         i_warning(e.get_msg().c_str());
>                                   ^
>                                   "%s",
> 1 warning generated.
>
>
> Is that something you can look into as well?
>
>
>
> On Mon, 14 Jan 2019 at 11:43, Joan Moreau  > wrote:
>
> THank you Odhiambo. I updated accordingly
>
>
>  
>
>
> On 2019-01-14 08:07, Odhiambo Washington wrote:
>
>> In your README.md, perhaps "This project intends to provide a
>> straightforward and simple *procedure *to configure FTS plugin
>> for Dovecot, leveraging the efforts by the Xapian.org team." is
>> better??
>> Also in the part after cloning from git:
>>  
>> ./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This
>> /path/to/dovecot is not obvious. Is it the dovecot binary or what??]
>>
>> On Mon, 14 Jan 2019 at 09:42, Joan Moreau via dovecot
>> mailto:dovecot@dovecot.org>> wrote:
>>
>> Thank you Stephan.
>>
>> The version here shall be up and running :
>> https://github.com/grosjo/fts-xapian
>>
>>
>>  
>>
>>
>> On 2019-01-14 00:07, Stephan Bosch wrote:
>>
>>
>>
>> Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot:
>>
>>
>> I tried to combined it, the "autoreconf" errors are solved
>>
>> Now, when I type "make install", the lib is not
>> pushed into dovecot folder, but somewhere in
>> /usr/local/...
>>
>> How to adjust this to have it arriving in the proper folder ?
>>
>>
>> Depends on your system. It mostly a matter of setting a
>> proper --prefix directory for configure, but other paths
>> are configurable as well. I usually check what the
>> official distribution package for Dovecot is doing and
>> use that as a basis.
>>
>> For Debian I use the following configure command:
>>
>> ./configure --with-ldap=plugin --with-ssl=openssl
>> --with-sql=plugin --with-lua=plugin --with-pgsql
>> --with-mysql --with-sqlite \
>>     --with-gssapi=plugin --with-solr
>> --with-ioloop=best --enable-maintainer-mode \
>>     --prefix=/usr --sysconfdir=/etc
>> --libexecdir=/usr/lib --localstatedir=/var
>> --mandir=/usr/share/man \
>>     --infodir=/usr/share/info
>> --with-moduledir=/usr/lib/dovecot/modules --disable-rpath
>> --disable-static
>>
>> Regards,
>>
>> Stephan
>>
>>
>> On 2019-01-13 21:01, Tuomi, Aki wrote:
>>
>> You copied 

Re: [FTS Xapian] Beta release

2019-01-14 Thread Odhiambo Washington
Testing a compile on FreeBSD.

gmake[2]: Entering directory '/usr/home/wash/Tools/Dovecot/fts-xapian/src'
/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
-I..  -I/opt/dovecot2.3/include/dovecot
-I/opt/dovecot2.3/include/dovecot  -g -O2 -MT fts-backend-xapian.lo -MD
-MP -MF .deps/fts-backend-xapian.Tpo -c -o fts-backend-xapian.lo
fts-backend-xapian.cpp
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I..
-I/opt/dovecot2.3/include/dovecot -I/opt/dovecot2.3/include/dovecot -g -O2
-MT fts-backend-xapian.lo -MD -MP -MF .deps/fts-backend-xapian.Tpo -c
fts-backend-xapian.cpp  -fPIC -DPIC -o .libs/fts-backend-xapian.o
fts-backend-xapian.cpp:3:10: fatal error: 'xapian.h' file not found
#include 
 ^~

Well, I installed xapian-core and the xapian.h is in /usr/local/include/

I can overcome the fatal error by doing:

 env CPPFLAGS=-I/usr/local/include PANDOC=false ./configure --prefix=/opt
--with-dovecot=/opt/dovecot2.3/lib/dovecot/

Is that something that you can address within the code or we (*BSD) have to
live with it?

During `make`, the following warning is generated:

/bin/sh ../libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
-I..  -I/opt/dovecot2.3/include/dovecot -I/usr/local/include
-I/opt/dovecot2.3/include/dovecot  -g -O2 -MT fts-backend-xapian.lo -MD
-MP -MF .deps/fts-backend-xapian.Tpo -c -o fts-backend-xapian.lo
fts-backend-xapian.cpp
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I..
-I/opt/dovecot2.3/include/dovecot -I/usr/local/include
-I/opt/dovecot2.3/include/dovecot -g -O2 -MT fts-backend-xapian.lo -MD -MP
-MF .deps/fts-backend-xapian.Tpo -c fts-backend-xapian.cpp  -fPIC -DPIC -o
.libs/fts-backend-xapian.o
fts-backend-xapian.cpp:486:14: warning: format string is not a string
literal (potentially insecure) [-Wformat-security]
i_warning(e.get_msg().c_str());
  ^~~
fts-backend-xapian.cpp:486:14: note: treat the string as an argument to
avoid this
i_warning(e.get_msg().c_str());
  ^
  "%s",
1 warning generated.


Is that something you can look into as well?



On Mon, 14 Jan 2019 at 11:43, Joan Moreau  wrote:

> THank you Odhiambo. I updated accordingly
>
>
>
>
>
> On 2019-01-14 08:07, Odhiambo Washington wrote:
>
> In your README.md, perhaps "This project intends to provide a
> straightforward and simple *procedure *to configure FTS plugin for
> Dovecot, leveraging the efforts by the Xapian.org team." is better??
> Also in the part after cloning from git:
>
> ./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This
> /path/to/dovecot is not obvious. Is it the dovecot binary or what??]
>
> On Mon, 14 Jan 2019 at 09:42, Joan Moreau via dovecot 
> wrote:
>
>> Thank you Stephan.
>>
>> The version here shall be up and running :
>> https://github.com/grosjo/fts-xapian
>>
>>
>>
>>
>>
>> On 2019-01-14 00:07, Stephan Bosch wrote:
>>
>>
>>
>> Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot:
>>
>>
>> I tried to combined it, the "autoreconf" errors are solved
>>
>> Now, when I type "make install", the lib is not pushed into dovecot
>> folder, but somewhere in /usr/local/...
>>
>> How to adjust this to have it arriving in the proper folder ?
>>
>>
>> Depends on your system. It mostly a matter of setting a proper --prefix
>> directory for configure, but other paths are configurable as well. I
>> usually check what the official distribution package for Dovecot is doing
>> and use that as a basis.
>>
>> For Debian I use the following configure command:
>>
>> ./configure --with-ldap=plugin --with-ssl=openssl --with-sql=plugin
>> --with-lua=plugin --with-pgsql --with-mysql --with-sqlite \
>> --with-gssapi=plugin --with-solr --with-ioloop=best
>> --enable-maintainer-mode \
>> --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
>> --localstatedir=/var --mandir=/usr/share/man \
>> --infodir=/usr/share/info
>> --with-moduledir=/usr/lib/dovecot/modules --disable-rpath --disable-static
>>
>> Regards,
>>
>> Stephan
>>
>>
>> On 2019-01-13 21:01, Tuomi, Aki wrote:
>>
>> You copied your Makefile.am there. Stephan made you a working version,
>> can you try that?
>> (sorry for dup)
>> Aki
>>  Original message 
>> From: Joan Moreau 
>> Date: 13/01/2019 21:39 (GMT+02:00)
>> To: Stephan Bosch 
>> Cc: Aki Tuomi 
>> Subject: Re: [FTS Xapian] Beta release
>>
>> I used the skeleton from Aki : https://github.com/grosjo/fts-xapian
>>
>> However, when I try to act as a visitor, I reach teh follwoing error:
>>
>> # autoreconf -vi
>> autoreconf: Entering directory `.'
>> autoreconf: configure.ac: not using Gettext
>> autoreconf: running: aclocal -I m4
>> autoreconf: configure.ac: tracing
>> autoreconf: running: libtoolize --copy
>> libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
>> libtoolize: copying file './ltmain.sh'
>> libtoolize: putting macros in AC_CONFI

Re: [FTS Xapian] Beta release

2019-01-14 Thread Paul Hecker via dovecot
Thank you. Here is the stack trace with all debug symbols:

(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7f88b6cc742a in __GI_abort () at abort.c:89
#2  0x7f88b5b240ad in __gnu_cxx::__verbose_terminate_handler() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x7f88b5b22066 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x7f88b5b220b1 in std::terminate() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x7f88b5b222c9 in __cxa_throw () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x7f88b5b227ec in operator new(unsigned long) () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x7f88b5e681b6 in 
__gnu_cxx::new_allocator, std::allocator > const, OmDocumentTerm> > 
>::allocate (this=, __n=1) at 
/usr/include/c++/6/ext/new_allocator.h:104
#8  
std::allocator_traits, std::allocator > const, OmDocumentTerm> > > 
>::allocate (__a=..., __n=1) at /usr/include/c++/6/bits/alloc_traits.h:436
#9  std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, OmDocumentTerm>, 
std::_Select1st, std::allocator > const, OmDocumentTerm> >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::_M_get_node (this=) at /usr/include/c++/6/bits/stl_tree.h:505
#10 std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, OmDocumentTerm>, 
std::_Select1st, std::allocator > const, OmDocumentTerm> >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::_M_create_node, std::allocator >, OmDocumentTerm> 
>(std::pair, 
std::allocator >, OmDocumentTerm>&&) (this=)
at /usr/include/c++/6/bits/stl_tree.h:559
#11 std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, OmDocumentTerm>, 
std::_Select1st, std::allocator > const, OmDocumentTerm> >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::_Alloc_node::operator(), std::allocator >, OmDocumentTerm> 
>(std::pair, 
std::allocator >, OmDocumentTerm>&&) const (
this=, __arg=) at 
/usr/include/c++/6/bits/stl_tree.h:473
#12 std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, OmDocumentTerm>, 
std::_Select1st, std::allocator > const, OmDocumentTerm> >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::_M_insert_, std::allocator >, OmDocumentTerm>, 
std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, OmDocumentTerm>, 
std::_Select1st, std::allocator > const, OmDocumentTerm> >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, 
std::pair, 
std::allocator >, OmDocumentTerm>&&, 
std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, OmDocumentTerm>, 
std::_Select1st, std::allocator > const, OmDocumentTerm> >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::_Alloc_node&) (__node_gen=..., __v=, __p=0x7f88b78c7010, __x=0x0, this=0x55d404f29c60)
at /usr/include/c++/6/bits/stl_tree.h:1535
#13 std::_Rb_tree, 
std::allocator >, std::pair, std::allocator > const, OmDocumentTerm>, 
std::_Select1st, std::allocator > const, OmDocumentTerm> >, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::_M_insert_unique, std::allocator >, OmDocumentTerm> 
>(std::pair, 
std::allocator >, OmDocumentTerm>&&) (
this=this@entry=0x55d404f29c60, __v=__v@entry=) at /usr/include/c++/6/bits/stl_tree.h:1894
#14 0x7f88b5e67282 in std::map, std::allocator >, OmDocumentTerm, 
std::less, 
std::allocator > >, 
std::allocator, std::allocator > const, OmDocumentTerm> > 
>::insert, 
std::allocator >, OmDocumentTerm>, 
void>(std::pair, 
std::allocator >, OmDocumentTerm>&&) (__x=, this=) at 
/usr/include/c++/6/bits/stl_map.h:740
#15 Xapian::Document::Internal::add_term (this=, 
tname="XMIDascoding.c", wdfinc=wdfinc@entry=1) at ../api/omdocument.cc:371
#16 0x7f88b5e672f9 in Xapian::Document::add_term 
(this=this@entry=0x7fff87c611a0, tname="XMIDascoding.c", wdfinc=wdfinc@entry=1) 
at ../api/omdocument.cc:139
#17 0x7f88b622e9e6 in fts_backend_xapian_index_hdr (dbx=0x55d3f840f9f0, 
uid=, field=, data=data@entry=0x55d40433af50 
"<4f31eb5f-7fcb-478d-91d0-12c0ae75a...@iwascoding.com>MESSAGE-ID", p=, f=)
at fts-backend-xapian-functions.cpp:661
#18 0x7f88b62325d6 in fts_backend_xapian_update_build_more 
(_ctx=0x55d3f827ef80, data=0x55d40433af50 
"<4f31eb5f-7fcb-478d-91d0-12c0ae75a...@iwascoding.com>MESSAGE-ID", 
size=) at fts-backend-xapian.cpp:330
#19 0x7f88b66439a8 in fts_build_data (ctx=ctx@entry=0x7fff87c61820, 
data=0x55d40433af50 
"<4f31eb5f-7fcb-478d-91d0-12c0ae75a...@iwascoding.com>MESSAGE-ID", size=53, 
last=last@entry=true) at fts-build-mail.c:425
#20 0x7f88b66441f7 in fts_build_unstructured_header (hdr=, 
hdr=, ctx=0x7fff87c61820) at fts-build-m

Re: mdbox import error from read-only filesystem

2019-01-14 Thread hby
Hi,

Thanks for the fast answer!

Let me clear the situation:
1. I want to import from a read-only filesystem where the mdbox files are
2. The indexes are necessary because of the mdbox file layout, but the
import process cannot open them
3. If I specify random writable dir for indexes the import does not do
anything, no message will be imported as obviously the indexes are
necessary for mdbox
4. The CONTROL parameter is only usable for maildir format

To make it more specific, I'm using the following command to restore the
messages right now:
doveadm -o mail_location=mdbox:/backup/restore/XXX -o
mail_attachment_dir=/mnt/_attachments backup -u XXX doveadm dsync-server -u
XXX

For this to work, I have to copy the full mdbox data to the writeable
/backup/restore/XXX. If I only change the INDEX location, the process still
tries to open the log files and fails with open() error on them.

Sami Ketola  ezt írta (időpont: 2019. jan. 14., H,
10:46):

> Hi,
>
> you can use INDEX=/writable/path/%u in your mail_location setting to
> define location for the required index data when importing.
> Also possibly you would need to define writable location for CONTROL and
> VOLATILEDIR.
>
> see https://wiki.dovecot.org/MailLocation
>
> Sami
>
> On 14 Jan 2019, at 11.23, hby  wrote:
>
> Dovecot version: 2.2.34
>
> doveadm import tries to call open() on the source indexes/logs of mdbox
> data, but even if it should work as it is just a read-related call, it
> fails on read-only filesystems.
>
> The main use case for read-only filesystem is restoring from backup: the
> massive deduplicated backup data is exposed using FUSE. For deduplication
> to work efficiently, we have to backup the whole mail storage and thus the
> only way to handle the restore to mount the whole data.
>
> I would like to ask for some proper solution for this problem.
>
> Suggestions: first, the doveadm import should never modify the indexes,
> and second: the open() calls should respect the read-only filesystem and
> should fall back to "r" flag when using open.
> The problem goes further when using SIS (which goes beyond multiple
> terrabytes).
>
> The only workaround currently is to export the whole mdbox data to a
> writeable storage, and parametrize the import command to use that and the
> mounted SIS data separately for import...which is just problematic, ugly
> and error prune.
>
> Thank you for the continous work on dovecot, I hope you get this feedback
> in a good way.
>
>
>


Re: Freebsd: Fatal error - Support not compiled in for passdb driver 'sql'

2019-01-14 Thread Odhiambo Washington
So maybe we should tell the OP that he needs to:

cd /usr/ports/mail/dovecot
make config [ select the MySQL option and save]
make install clean.

[He's probably coming from Linux world to FreeBSD]


 On Mon, 14 Jan 2019 at 13:25, Larry Rosenman  wrote:

> Ports has the options, I'm just not changing the defaults.
>
> Get Outlook for Android 
>
> --
> *From:* dovecot  on behalf of Odhiambo
> Washington 
> *Sent:* Monday, January 14, 2019 3:47:43 AM
> *To:* gsjarvis
> *Cc:* Dovecot Mailing List
> *Subject:* Re: Freebsd: Fatal error - Support not compiled in for passdb
> driver 'sql'
>
>
>
> On Sun, 13 Jan 2019 at 22:15, gsjarvis  wrote:
>
>> Hello,
>>
>> I was wondering if there was any progress on this.
>>
>> I just upgraded a FreeBSD box and had the same issue again.
>>
>> I keep (reasonably) good support notes so I found the one that said I had
>> to
>> install from ports - so all is well. I was just wondering if there was any
>> news.
>>
>> I look forward to hearing from you.
>>
>> Thanks,
>>
>> -Graham-
>>
>>
>
> I have run RC versions and well as RELEASE versions on FreeBSD and I
> always compile with (/opt path relative to version):
> ./configure \
> --prefix=/opt/dovecot2.3 \
> --with-ioloop=kqueue \
> --with-notify=kqueue \
> --with-sql=yes \
> --with-mysql \
> --with-zlib \
> --with-bzlib \
> --with-ssl=openssl
> gmake install
>
>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft.", grep ^[^#] :-)
>


-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)


Re: [solved] managesieve configuration

2019-01-14 Thread Dominik Menke

On 1/14/19 11:02 AM, Stephan Bosch wrote:

Op 14-1-2019 om 9:58 schreef Dominik Menke:

On 1/13/19 12:23 PM, Stephan Bosch wrote:
With ssl=yes, the TLS layer is enabled immediately on the connection. 



Again, that's not what the documentation says:

    ssl=yes [...]: SSL/TLS is offered to the client, but the client
    isn't required to use it.

If the client is not _required_ to use it, it _may_ chose plaintext 
transport, no?


(I'm not here to argue, I'm just pointing out an issue with the wiki).


Oh, I think we are talking about different things here. You're talking 
about the global ssl= setting. I am talking about the ssl = yes inside 
the service listener configuration 
(https://wiki.dovecot.org/Services#inet_listeners). The former specifies 
whether SSL is available/required for user connections in general, 
whereas the latter specifies whether the service activates the TLS layer 
immediately for that particular listener. The latter is also where you 
made the configuration mistake.




Oh, I see! Thanks for the clarification :-)
--Dominik


Re: Freebsd: Fatal error - Support not compiled in for passdb driver 'sql'

2019-01-14 Thread Larry Rosenman
Ports has the options, I'm just not changing the defaults.

Get Outlook for Android


From: dovecot  on behalf of Odhiambo Washington 

Sent: Monday, January 14, 2019 3:47:43 AM
To: gsjarvis
Cc: Dovecot Mailing List
Subject: Re: Freebsd: Fatal error - Support not compiled in for passdb driver 
'sql'



On Sun, 13 Jan 2019 at 22:15, gsjarvis mailto:gsjar...@pt.lu>> 
wrote:
Hello,

I was wondering if there was any progress on this.

I just upgraded a FreeBSD box and had the same issue again.

I keep (reasonably) good support notes so I found the one that said I had to
install from ports - so all is well. I was just wondering if there was any
news.

I look forward to hearing from you.

Thanks,

-Graham-



I have run RC versions and well as RELEASE versions on FreeBSD and I always 
compile with (/opt path relative to version):
./configure \
--prefix=/opt/dovecot2.3 \
--with-ioloop=kqueue \
--with-notify=kqueue \
--with-sql=yes \
--with-mysql \
--with-zlib \
--with-bzlib \
--with-ssl=openssl
gmake install



--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)


Re: [FTS Xapian] Beta release

2019-01-14 Thread Stephan Bosch



Op 14-1-2019 om 10:55 schreef Paul Hecker via dovecot:
OK, got it (my fault, as always, put the LimitCORE in the wrong line). 
Here is the stack trace:


If you want to get rid of those "??" stack trace elements, you'll need 
to install debug symbols for the xapian library. It depends on your 
system how to do that (usually some separate package).



Regards,

Stephan.





On 14. Jan 2019, at 10:33, Joan Moreau via dovecot 
mailto:dovecot@dovecot.org>> wrote:


Difficult to figure out without a coredump + gdb


I have also battled quite a lot to make sure dovecot can core dump on 
my Archlinux servers.


I remember that the key point was putting*fs.suid_dumpable=2* in 
/etc/sysctl.d/ conf files, *LimitCORE=infinity* 
in /etc/systemd/system/multi-user.target.wants/dovecot.service,  and 
rebooting the server.


My own coredumps are on /var/lib/systemd/coredump/






Re: [solved] managesieve configuration

2019-01-14 Thread Stephan Bosch



Op 14-1-2019 om 9:58 schreef Dominik Menke:

On 1/13/19 12:23 PM, Stephan Bosch wrote:
With ssl=yes, the TLS layer is enabled immediately on the connection. 



Again, that's not what the documentation says:

    ssl=yes [...]: SSL/TLS is offered to the client, but the client
    isn't required to use it.

If the client is not _required_ to use it, it _may_ chose plaintext 
transport, no?


(I'm not here to argue, I'm just pointing out an issue with the wiki).


Oh, I think we are talking about different things here. You're talking 
about the global ssl= setting. I am talking about the ssl = yes inside 
the service listener configuration 
(https://wiki.dovecot.org/Services#inet_listeners). The former specifies 
whether SSL is available/required for user connections in general, 
whereas the latter specifies whether the service activates the TLS layer 
immediately for that particular listener. The latter is also where you 
made the configuration mistake.



Regards,

Stephan



Re: [FTS Xapian] Beta release

2019-01-14 Thread Paul Hecker via dovecot
OK, got it (my fault, as always, put the LimitCORE in the wrong line). Here is the stack trace:(gdb) bt 
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fe342b0942a in __GI_abort () at abort.c:89
#2  0x7fe3419660ad in __gnu_cxx::__verbose_terminate_handler() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x7fe341964066 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x7fe3419640b1 in std::terminate() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x7fe3419642c9 in __cxa_throw () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x7fe3419647ec in operator new(unsigned long) () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x7fe341ca748d in ?? () from /usr/lib/x86_64-linux-gnu/libxapian.so.30
#8  0x7fe341ca9258 in 
Xapian::Document::Internal::add_term(std::__cxx11::basic_string, std::allocator > const&, unsigned int) () from 
/usr/lib/x86_64-linux-gnu/libxapian.so.30
#9  0x7fe341ca92f9 in 
Xapian::Document::add_term(std::__cxx11::basic_string, std::allocator > const&, unsigned int) () from 
/usr/lib/x86_64-linux-gnu/libxapian.so.30
#10 0x7fe3420709e6 in fts_backend_xapian_index_hdr (dbx=0x56307b00, 
uid=, field=, data=data@entry=0x56301cf420e0 
"MESSAGE-ID", p=, f=)
at fts-backend-xapian-functions.cpp:661
#11 0x7fe3420745d6 in fts_backend_xapian_update_build_more 
(_ctx=0x56301117e0a0, data=0x56301cf420e0 
"MESSAGE-ID", 
size=) at fts-backend-xapian.cpp:330
#12 0x7fe3424859a8 in fts_build_data (ctx=ctx@entry=0x7ffeb9c7d3a0, 
data=0x56301cf420e0 
"MESSAGE-ID", size=53, 
last=last@entry=true) at fts-build-mail.c:425
#13 0x7fe3424861f7 in fts_build_unstructured_header (hdr=, 
hdr=, ctx=0x7ffeb9c7d3a0) at fts-build-mail.c:103
#14 fts_build_mail_header (block=0x7ffeb9c7d330, block=0x7ffeb9c7d330, 
ctx=0x7ffeb9c7d3a0) at fts-build-mail.c:178
#15 fts_build_mail_real (may_need_retry_r=0x7ffeb9c7d2e3, 
retriable_err_msg_r=0x7ffeb9c7d2f0, mail=0x5630111b9a08, 
update_ctx=0x56301117e0a0) at fts-build-mail.c:568
#16 fts_build_mail (update_ctx=0x56301117e0a0, mail=mail@entry=0x5630111b9a08) 
at fts-build-mail.c:617
#17 0x7fe34248d6c3 in fts_mail_index (_mail=0x5630111b9a08) at 
fts-storage.c:538
#18 fts_mail_precache (_mail=0x5630111b9a08) at fts-storage.c:559
#19 0x7fe343237d6a in mail_precache (mail=0x5630111b9a08) at mail.c:424
#20 0x56300ff5a603 in index_mailbox_precache (conn=0x5630110e99e0, 
box=0x56303fc8) at master-connection.c:102
#21 index_mailbox (user=, user=, what=, max_recent_msgs=, mailbox=, 
conn=0x5630110e99e0) at master-connection.c:205
#22 master_connection_input_line (line=, conn=0x5630110e99e0) at 
master-connection.c:247
#23 master_connection_input (conn=0x5630110e99e0) at master-connection.c:287
#24 0x7fe342f5f5d5 in io_loop_call_io (io=0x5630110e9a20) at ioloop.c:698
#25 0x7fe342f60fd9 in io_loop_handler_run_internal 
(ioloop=ioloop@entry=0x5630110dec90) at ioloop-epoll.c:221
#26 0x7fe342f5f6e6 in io_loop_handler_run (ioloop=) at 
ioloop.c:750
#27 0x7fe342f5f8f8 in io_loop_run (ioloop=0x5630110dec90) at ioloop.c:723
#28 0x7fe342ed3d43 in master_service_run (service=0x5630110deb20, 
callback=) at master-service.c:781
#29 0x56300ff59fea in main (argc=, argv=) at 
indexer-worker.c:77












(gdb) bt full
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
set = {__val = {0, 51539607553, 0, 140732015298048, 3, 0, 
7233170478761014387, 109330211561823, 140732015303136, 140732015302656, 
140732015303144, 0, 140732015303160, 0, 0, 0}}
pid = 
tid = 
#1  0x7fe342b0942a in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7fe342e6f520 
<_IO_2_1_stderr_>, sa_sigaction = 0x7fe342e6f520 <_IO_2_1_stderr_>}, sa_mask = 
{__val = {3432, 140614056716544, 140614056719424, 140614056736163, 
140614053423970, 14, 1, 10, 0, 94764659026720, 50, 
  140732015300080, 140614053431513, 140614056736032, 
140614053432547, 140614056736032}}, sa_flags = 1100362432, sa_restorer = 0x0}
sigs = {__val = {32, 0 }}
#2  0x7fe3419660ad in __gnu_cxx::__verbose_terminate_handler() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0x7fe341964066 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#4  0x7fe3419640b1 in std::terminate() () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#5  0x7fe3419642c9 in __cxa_throw () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#6  0x7fe3419647ec in operator new(unsigned long) () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
No symbol table info available.
#7  0x7fe341ca748d in ?? () from /usr/lib/x86_64-linux-gnu/libxapian.so.30
No symbol table info available.
#8  0x7fe341ca9258 in 
Xapian::Document::Internal::add_term(std::__cxx11::basic_string, std::a

Re: Freebsd: Fatal error - Support not compiled in for passdb driver 'sql'

2019-01-14 Thread Odhiambo Washington
On Sun, 13 Jan 2019 at 22:15, gsjarvis  wrote:

> Hello,
>
> I was wondering if there was any progress on this.
>
> I just upgraded a FreeBSD box and had the same issue again.
>
> I keep (reasonably) good support notes so I found the one that said I had
> to
> install from ports - so all is well. I was just wondering if there was any
> news.
>
> I look forward to hearing from you.
>
> Thanks,
>
> -Graham-
>
>

I have run RC versions and well as RELEASE versions on FreeBSD and I always
compile with (/opt path relative to version):
./configure \
--prefix=/opt/dovecot2.3 \
--with-ioloop=kqueue \
--with-notify=kqueue \
--with-sql=yes \
--with-mysql \
--with-zlib \
--with-bzlib \
--with-ssl=openssl
gmake install



-- 
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)


Re: mdbox import error from read-only filesystem

2019-01-14 Thread Sami Ketola
Hi,

you can use INDEX=/writable/path/%u in your mail_location setting to define 
location for the required index data when importing.
Also possibly you would need to define writable location for CONTROL and 
VOLATILEDIR. 

see https://wiki.dovecot.org/MailLocation 


Sami

> On 14 Jan 2019, at 11.23, hby  wrote:
> 
> Dovecot version: 2.2.34
> 
> doveadm import tries to call open() on the source indexes/logs of mdbox data, 
> but even if it should work as it is just a read-related call, it fails on 
> read-only filesystems.
> 
> The main use case for read-only filesystem is restoring from backup: the 
> massive deduplicated backup data is exposed using FUSE. For deduplication to 
> work efficiently, we have to backup the whole mail storage and thus the only 
> way to handle the restore to mount the whole data.
> 
> I would like to ask for some proper solution for this problem.
> 
> Suggestions: first, the doveadm import should never modify the indexes, and 
> second: the open() calls should respect the read-only filesystem and should 
> fall back to "r" flag when using open.
> The problem goes further when using SIS (which goes beyond multiple 
> terrabytes).
> 
> The only workaround currently is to export the whole mdbox data to a 
> writeable storage, and parametrize the import command to use that and the 
> mounted SIS data separately for import...which is just problematic, ugly and 
> error prune.
> 
> Thank you for the continous work on dovecot, I hope you get this feedback in 
> a good way.



Re: [FTS Xapian] Beta release

2019-01-14 Thread Joan Moreau via dovecot
Difficult to figure out without a coredump + gdb 


I have also battled quite a lot to make sure dovecot can core dump on my
Archlinux servers. 


I remember that the key point was putting FS.SUID_DUMPABLE=2 in
/etc/sysctl.d/ conf files, LIMITCORE=INFINITY in
/etc/systemd/system/multi-user.target.wants/dovecot.service,  and
rebooting the server. 

My own coredumps are on /var/lib/systemd/coredump/ 


On 2019-01-14 10:20, Paul Hecker via dovecot wrote:

Here it is: 


Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Effective uid=8, gid=8, home=/var/spool/mail/iwascoding/paul
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota root: name=User quota backend=dict 
args=:file:/var/spool/mail/iwascoding/paul/dovecot-quota
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota rule: root=User quota mailbox=* bytes=2147483648 messages=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota rule: root=User quota mailbox=* bytes=2147483648 messages=6
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota grace: root=User quota bytes=214748364 (10%)
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: dict 
quota: user=p...@iwascoding.com, uri=file:/var/spool/mail/iwascoding/paul/dovecot-quota, 
noenforcing=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, 
subscriptions=yes location=mdbox:~/mdbox
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: fs: 
root=/var/spool/mail/iwascoding/paul/mdbox, index=, indexpvt=, control=, inbox=, alt=
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: FTS Xapian: 
Partial=2, Full=20 DB_PATH=/var/spool/mail/iwascoding/paul/mdbox/xapian-indexes
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
quota: quota_over_flag check: quota_over_script unset - skipping
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: Mailbox opened because: indexing
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: FTS Xapian 
: Mailbox sent : Last UID=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: FTS Xapian 
: Mailbox sent : Last UID=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Namespace : Using permissions from /var/spool/mail/iwascoding/paul/mdbox: mode=0700 
gid=default
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 1: Opened mail because: fts indexing
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Opening RW 
/var/spool/mail/iwascoding/paul/mdbox/xapian-indexes/db_9ddfe10d8a8a8a568c12654d370e
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 2: Opened mail because: fts indexing
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 3: Opened mail because: fts indexing

Thank you! 

On 14. Jan 2019, at 10:11, Joan Moreau via dovecot  wrote: 

Can you send the log part that includes the "init" of the plugins (something similar as below) ? 

WHich version of Xapian are you on ? 


Jan 14 09:10:04 gjserver dovecot[31082]: 
indexer-worker(ad...@grosjo.net)<14725>:
 FTS Xapian: Partial=2, Full=20 DB_PATH=/data/mail/grosjo.net/admin/xapian-indexes [1]
Jan 14 09:10:04 gjserver dovecot[31082]: 
indexer-worker(ad...@grosjo.net)<14725>:
 FTS Xapian : Mailbox Mail : Last UID=815055
Jan 14 09:10:04 gjserver dovecot[31082]: 
indexer-worker(ad...@grosjo.net)<14725>:
 FTS Xapian : Mailbox Mail : Last UID=815055
Jan 14 09:10:04 gjserver dovecot[31082]: indexer-worker(ad...@grosjo.net)<14725>: Opening RW /data/mail/grosjo.net/admin/xapian-indexes/db_5c935034609bc14c0e55d6a3092d [2] 

On 2019-01-14 10:08, Paul Hecker via dovecot wrote: 
Hi,


I installed and tested your version, but the indexer process crashes 
reproducible with the following command after about 2000 messages were indexed:

doveadm index -u p...@iwascoding.com -q \*

Jan 14 09:26:15 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 2038: Opened mail because: fts indexing
Jan 14 09:26:15 mail dovecot: indexer-worker: Error: terminate called after 
throwing an instance of 'std::bad_alloc'
Jan 14 09:26:15 mail dovecot: indexer-worker: Error:   what():  std::bad_alloc
Jan 14 09:26:15 mail dovecot: indexer: Error: Indexer worker disconnected, 
discarding 48 requests for p...@iwascoding.com
Jan 14 09:26:15 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Fatal: 
master: service(indexer-worker): child 16777 killed with signal 6 (core dumps disabled - 
https://dovecot.org/bugreport.html#coredumps

mdbox import error from read-only filesystem

2019-01-14 Thread hby
Dovecot version: 2.2.34

doveadm import tries to call open() on the source indexes/logs of mdbox
data, but even if it should work as it is just a read-related call, it
fails on read-only filesystems.

The main use case for read-only filesystem is restoring from backup: the
massive deduplicated backup data is exposed using FUSE. For deduplication
to work efficiently, we have to backup the whole mail storage and thus the
only way to handle the restore to mount the whole data.

I would like to ask for some proper solution for this problem.

Suggestions: first, the doveadm import should never modify the indexes, and
second: the open() calls should respect the read-only filesystem and should
fall back to "r" flag when using open.
The problem goes further when using SIS (which goes beyond multiple
terrabytes).

The only workaround currently is to export the whole mdbox data to a
writeable storage, and parametrize the import command to use that and the
mounted SIS data separately for import...which is just problematic, ugly
and error prune.

Thank you for the continous work on dovecot, I hope you get this feedback
in a good way.


Re: [FTS Xapian] Beta release

2019-01-14 Thread Paul Hecker via dovecot
Here it is:

Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Effective uid=8, gid=8, home=/var/spool/mail/iwascoding/paul
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota root: name=User quota backend=dict 
args=:file:/var/spool/mail/iwascoding/paul/dovecot-quota
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota rule: root=User quota mailbox=* bytes=2147483648 messages=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota rule: root=User quota mailbox=* bytes=2147483648 messages=6
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Quota grace: root=User quota bytes=214748364 (10%)
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: dict 
quota: user=p...@iwascoding.com, 
uri=file:/var/spool/mail/iwascoding/paul/dovecot-quota, noenforcing=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, 
subscriptions=yes location=mdbox:~/mdbox
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: fs: 
root=/var/spool/mail/iwascoding/paul/mdbox, index=, indexpvt=, control=, 
inbox=, alt=
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: FTS Xapian: 
Partial=2, Full=20 DB_PATH=/var/spool/mail/iwascoding/paul/mdbox/xapian-indexes
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
quota: quota_over_flag check: quota_over_script unset - skipping
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: Mailbox opened because: indexing
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: FTS Xapian 
: Mailbox sent : Last UID=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: FTS Xapian 
: Mailbox sent : Last UID=0
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Namespace : Using permissions from /var/spool/mail/iwascoding/paul/mdbox: 
mode=0700 gid=default
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 1: Opened mail because: fts indexing
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Opening RW 
/var/spool/mail/iwascoding/paul/mdbox/xapian-indexes/db_9ddfe10d8a8a8a568c12654d370e
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 2: Opened mail because: fts indexing
Jan 14 09:26:08 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 3: Opened mail because: fts indexing

Thank you!


> On 14. Jan 2019, at 10:11, Joan Moreau via dovecot  
> wrote:
> 
> Can you send the log part that includes the "init" of the plugins (something 
> similar as below) ?
> 
> WHich version of Xapian are you on ?
> 
> Jan 14 09:10:04 gjserver dovecot[31082]: 
> indexer-worker(ad...@grosjo.net)<14725>:
>  FTS Xapian: Partial=2, Full=20 
> DB_PATH=/data/mail/grosjo.net/admin/xapian-indexes
> Jan 14 09:10:04 gjserver dovecot[31082]: 
> indexer-worker(ad...@grosjo.net)<14725>:
>  FTS Xapian : Mailbox Mail : Last UID=815055
> Jan 14 09:10:04 gjserver dovecot[31082]: 
> indexer-worker(ad...@grosjo.net)<14725>:
>  FTS Xapian : Mailbox Mail : Last UID=815055
> Jan 14 09:10:04 gjserver dovecot[31082]: 
> indexer-worker(ad...@grosjo.net)<14725>:
>  Opening RW 
> /data/mail/grosjo.net/admin/xapian-indexes/db_5c935034609bc14c0e55d6a3092d
> 
> 
> 
>  
> 
> 
> On 2019-01-14 10:08, Paul Hecker via dovecot wrote:
> 
>> Hi,
>> 
>> I installed and tested your version, but the indexer process crashes 
>> reproducible with the following command after about 2000 messages were 
>> indexed:
>> 
>> doveadm index -u p...@iwascoding.com  -q \*
>> 
>> Jan 14 09:26:15 mail dovecot: indexer-worker(p...@iwascoding.com 
>> )<16777>: Debug: Mailbox 
>> sent: UID 2038: Opened mail because: fts indexing
>> Jan 14 09:26:15 mail dovecot: indexer-worker: Error: terminate called after 
>> throwing an instance of 'std::bad_alloc'
>> Jan 14 09:26:15 mail dovecot: indexer-worker: Error:   what():  
>> std::bad_alloc
>> Jan 14 09:26:15 mail dovecot: indexer: Error: Indexer worker disconnected, 
>> discarding 48 requests for p...@iwascoding.com 
>> Jan 14 09:26:15 mail dovecot: indexer-worker(p...@iwascoding.com 
>> )<16777>: Fatal: master: 
>> service(indexer-worker): child 16777 killed with signal 6 (core dumps 
>> disabled - https://dovecot.org/bugreport.html#coredumps 
>> )
>> 
>> I tried to delete the message, but this does not help (crashes e.g. after 
>> message 2029 or 2044). Other folders with fewer messages were successfully 
>> in

Re: [FTS Xapian] Beta release

2019-01-14 Thread Paul Hecker via dovecot
Here it is:

Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Effective 
uid=8, gid=8, home=/var/spool/mail/iwascoding/paul
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Quota 
root: name=User quota backend=dict 
args=:file:/var/spool/mail/iwascoding/paul/dovecot-quota
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Quota 
rule: root=User quota mailbox=* bytes=2147483648 messages=0
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Quota 
rule: root=User quota mailbox=* bytes=2147483648 messages=6
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Quota 
grace: root=User quota bytes=214748364 (10%)
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: dict 
quota: user=p...@iwascoding.com , 
uri=file:/var/spool/mail/iwascoding/paul/dovecot-quota, noenforcing=0
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Namespace 
inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no, list=yes, 
subscriptions=yes location=mdbox:~/mdbox
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: fs: 
root=/var/spool/mail/iwascoding/paul/mdbox, index=, indexpvt=, control=, 
inbox=, alt=
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: FTS Xapian: 
Partial=2, Full=20 DB_PATH=/var/spool/mail/iwascoding/paul/mdbox/xapian-indexes
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: quota: 
quota_over_flag check: quota_over_script unset - skipping
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Mailbox 
sent: Mailbox opened because: indexing
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: FTS Xapian : 
Mailbox sent : Last UID=0
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: FTS Xapian : 
Mailbox sent : Last UID=0
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Namespace 
: Using permissions from /var/spool/mail/iwascoding/paul/mdbox: mode=0700 
gid=default
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Mailbox 
sent: UID 1: Opened mail because: fts indexing
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Opening RW 
/var/spool/mail/iwascoding/paul/mdbox/xapian-indexes/db_9ddfe10d8a8a8a568c12654d370e
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Mailbox 
sent: UID 2: Opened mail because: fts indexing
Jan 14 09:26:08 mail dovecot: indexer-worker(p...@iwascoding.com 
)<16777>: Debug: Mailbox 
sent: UID 3: Opened mail because: fts indexing

Thank you!


> On 14. Jan 2019, at 10:11, Joan Moreau via dovecot  > wrote:
> 
> Can you send the log part that includes the "init" of the plugins (something 
> similar as below) ?
> 
> WHich version of Xapian are you on ?
> 
> Jan 14 09:10:04 gjserver dovecot[31082]: indexer-worker(ad...@grosjo.net 
> )<14725>:
>  FTS Xapian: Partial=2, Full=20 
> DB_PATH=/data/mail/grosjo.net/admin/xapian-indexes 
> 
> Jan 14 09:10:04 gjserver dovecot[31082]: indexer-worker(ad...@grosjo.net 
> )<14725>:
>  FTS Xapian : Mailbox Mail : Last UID=815055
> Jan 14 09:10:04 gjserver dovecot[31082]: indexer-worker(ad...@grosjo.net 
> )<14725>:
>  FTS Xapian : Mailbox Mail : Last UID=815055
> Jan 14 09:10:04 gjserver dovecot[31082]: indexer-worker(ad...@grosjo.net 
> )<14725>:
>  Opening RW 
> /data/mail/grosjo.net/admin/xapian-indexes/db_5c935034609bc14c0e55d6a3092d
>  
> 
>  
> 
> 
> On 2019-01-14 10:08, Paul Hecker via dovecot wrote:
> 
>> Hi,
>> 
>> I installed and tested your version, but the indexer process crashes 
>> reproducible with the following command after about 2000 messages were 
>> indexed:
>> 
>> doveadm index -u p...@iwascoding.com  -q \*
>> 
>> Jan 14 09:26:15 mail dovecot: indexer-worker(p...@iwascoding.com 
>> )<16777>: Debug: Mailbox 
>> sent: UID 2038: Opened mail because: fts indexing
>> Jan 14 09:26:15 mail dovecot: indexer

Re: [FTS Xapian] Beta release

2019-01-14 Thread Joan Moreau via dovecot

Can you send the log part that includes the "init" of the plugins
(something similar as below) ? 

WHich version of Xapian are you on ? 


Jan 14 09:10:04 gjserver dovecot[31082]:
indexer-worker(ad...@grosjo.net)<14725>:
FTS Xapian: Partial=2, Full=20
DB_PATH=/data/mail/grosjo.net/admin/xapian-indexes
Jan 14 09:10:04 gjserver dovecot[31082]:
indexer-worker(ad...@grosjo.net)<14725>:
FTS Xapian : Mailbox Mail : Last UID=815055
Jan 14 09:10:04 gjserver dovecot[31082]:
indexer-worker(ad...@grosjo.net)<14725>:
FTS Xapian : Mailbox Mail : Last UID=815055
Jan 14 09:10:04 gjserver dovecot[31082]:
indexer-worker(ad...@grosjo.net)<14725>:
Opening RW
/data/mail/grosjo.net/admin/xapian-indexes/db_5c935034609bc14c0e55d6a3092d


On 2019-01-14 10:08, Paul Hecker via dovecot wrote:


Hi,

I installed and tested your version, but the indexer process crashes 
reproducible with the following command after about 2000 messages were indexed:

doveadm index -u p...@iwascoding.com -q \*

Jan 14 09:26:15 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 2038: Opened mail because: fts indexing
Jan 14 09:26:15 mail dovecot: indexer-worker: Error: terminate called after 
throwing an instance of 'std::bad_alloc'
Jan 14 09:26:15 mail dovecot: indexer-worker: Error:   what():  std::bad_alloc
Jan 14 09:26:15 mail dovecot: indexer: Error: Indexer worker disconnected, 
discarding 48 requests for p...@iwascoding.com
Jan 14 09:26:15 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Fatal: 
master: service(indexer-worker): child 16777 killed with signal 6 (core dumps disabled - 
https://dovecot.org/bugreport.html#coredumps)

I tried to delete the message, but this does not help (crashes e.g. after 
message 2029 or 2044). Other folders with fewer messages were successfully 
indexed before.

Sorry, could not convince dovecot to create core dumps (read the docs, changed 
/proc/sys/kernel/core_pattern, added LimitCORE=unlimited/infinity, even created 
/etc/systemd/system/dovecot.service.d/coredump.conf to no avail). Custom 
Dovecot 2.3.4 on Debian Stretch.

Thanks,
Paul

On 14. Jan 2019, at 07:42, Joan Moreau via dovecot  wrote:

Thank you Stephan.

The version here shall be up and running : https://github.com/grosjo/fts-xapian

On 2019-01-14 00:07, Stephan Bosch wrote:

Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot: 
I tried to combined it, the "autoreconf" errors are solved


Now, when I type "make install", the lib is not pushed into dovecot folder, but 
somewhere in /usr/local/...

How to adjust this to have it arriving in the proper folder ?

Depends on your system. It mostly a matter of setting a proper --prefix 
directory for configure, but other paths are configurable as well. I usually 
check what the official distribution package for Dovecot is doing and use that 
as a basis.

For Debian I use the following configure command:

./configure --with-ldap=plugin --with-ssl=openssl --with-sql=plugin 
--with-lua=plugin --with-pgsql --with-mysql --with-sqlite \
--with-gssapi=plugin --with-solr --with-ioloop=best --enable-maintainer-mode \
--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var 
--mandir=/usr/share/man \
--infodir=/usr/share/info --with-moduledir=/usr/lib/dovecot/modules 
--disable-rpath --disable-static

Regards,

Stephan

On 2019-01-13 21:01, Tuomi, Aki wrote:

You copied your Makefile.am there. Stephan made you a working version, can you 
try that?
(sorry for dup)
Aki
 Original message 
From: Joan Moreau 
Date: 13/01/2019 21:39 (GMT+02:00)
To: Stephan Bosch 
Cc: Aki Tuomi 
Subject: Re: [FTS Xapian] Beta release

I used the skeleton from Aki : https://github.com/grosjo/fts-xapian

However, when I try to act as a visitor, I reach teh follwoing error:

# autoreconf -vi
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:9: installing './compile'
configure.ac:11: installing './config.guess'
configure.ac:11: installing './config.sub'
configure.ac:7: installing './install-sh'
configure.ac:7: installing './missing'
src/Makefile.am: installing './depcomp'
/usr/share/automake-1.16/am/depend2.am: error: am__fastdepCXX does not appear 
in AM_CONDITIONAL
/usr/share/automake-1.16/am/depend2.am: The usual way to define 
'am__fastdepCXX' is to add 'AC_PROG_CXX'
/usr/share/automake-1.16/am/depend2.am

Re: [FTS Xapian] Beta release

2019-01-14 Thread Paul Hecker via dovecot
Hi,

I installed and tested your version, but the indexer process crashes 
reproducible with the following command after about 2000 messages were indexed:

doveadm index -u p...@iwascoding.com -q \*

Jan 14 09:26:15 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Debug: 
Mailbox sent: UID 2038: Opened mail because: fts indexing
Jan 14 09:26:15 mail dovecot: indexer-worker: Error: terminate called after 
throwing an instance of 'std::bad_alloc'
Jan 14 09:26:15 mail dovecot: indexer-worker: Error:   what():  std::bad_alloc
Jan 14 09:26:15 mail dovecot: indexer: Error: Indexer worker disconnected, 
discarding 48 requests for p...@iwascoding.com
Jan 14 09:26:15 mail dovecot: 
indexer-worker(p...@iwascoding.com)<16777>: Fatal: 
master: service(indexer-worker): child 16777 killed with signal 6 (core dumps 
disabled - https://dovecot.org/bugreport.html#coredumps)

I tried to delete the message, but this does not help (crashes e.g. after 
message 2029 or 2044). Other folders with fewer messages were successfully 
indexed before.

Sorry, could not convince dovecot to create core dumps (read the docs, changed 
/proc/sys/kernel/core_pattern, added LimitCORE=unlimited/infinity, even created 
/etc/systemd/system/dovecot.service.d/coredump.conf to no avail). Custom 
Dovecot 2.3.4 on Debian Stretch.

Thanks,
Paul


> On 14. Jan 2019, at 07:42, Joan Moreau via dovecot  
> wrote:
> 
> Thank you Stephan.
> 
> The version here shall be up and running : 
> https://github.com/grosjo/fts-xapian
> 
> 
> 
>  
> 
> 
> On 2019-01-14 00:07, Stephan Bosch wrote:
> 
>> 
>> 
>> Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot:
>>> 
>>> I tried to combined it, the "autoreconf" errors are solved
>>> 
>>> Now, when I type "make install", the lib is not pushed into dovecot folder, 
>>> but somewhere in /usr/local/...
>>> 
>>> How to adjust this to have it arriving in the proper folder ?
>>> 
>> 
>> Depends on your system. It mostly a matter of setting a proper --prefix 
>> directory for configure, but other paths are configurable as well. I usually 
>> check what the official distribution package for Dovecot is doing and use 
>> that as a basis.
>> 
>> For Debian I use the following configure command:
>> 
>> ./configure --with-ldap=plugin --with-ssl=openssl --with-sql=plugin 
>> --with-lua=plugin --with-pgsql --with-mysql --with-sqlite \
>> --with-gssapi=plugin --with-solr --with-ioloop=best 
>> --enable-maintainer-mode \
>> --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib 
>> --localstatedir=/var --mandir=/usr/share/man \
>> --infodir=/usr/share/info --with-moduledir=/usr/lib/dovecot/modules 
>> --disable-rpath --disable-static
>> 
>> Regards,
>> 
>> Stephan
>> 
>>> 
>>> On 2019-01-13 21:01, Tuomi, Aki wrote:
>>> 
 You copied your Makefile.am there. Stephan made you a working version, can 
 you try that?
 (sorry for dup)
 Aki
  Original message 
 From: Joan Moreau 
 Date: 13/01/2019 21:39 (GMT+02:00)
 To: Stephan Bosch 
 Cc: Aki Tuomi 
 Subject: Re: [FTS Xapian] Beta release
 
 I used the skeleton from Aki : https://github.com/grosjo/fts-xapian
 
 However, when I try to act as a visitor, I reach teh follwoing error:
 
 # autoreconf -vi
 autoreconf: Entering directory `.'
 autoreconf: configure.ac: not using Gettext
 autoreconf: running: aclocal -I m4
 autoreconf: configure.ac: tracing
 autoreconf: running: libtoolize --copy
 libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
 libtoolize: copying file './ltmain.sh'
 libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
 libtoolize: copying file 'm4/libtool.m4'
 libtoolize: copying file 'm4/ltoptions.m4'
 libtoolize: copying file 'm4/ltsugar.m4'
 libtoolize: copying file 'm4/ltversion.m4'
 libtoolize: copying file 'm4/lt~obsolete.m4'
 autoreconf: running: /usr/bin/autoconf
 autoreconf: running: /usr/bin/autoheader
 autoreconf: running: automake --add-missing --copy --no-force
 configure.ac:9: installing './compile'
 configure.ac:11: installing './config.guess'
 configure.ac:11: installing './config.sub'
 configure.ac:7: installing './install-sh'
 configure.ac:7: installing './missing'
 src/Makefile.am: installing './depcomp'
 /usr/share/automake-1.16/am/depend2.am: error: am__fastdepCXX does not 
 appear in AM_CONDITIONAL
 /usr/share/automake-1.16/am/depend2.am: The usual way to define 
 'am__fastdepCXX' is to add 'AC_PROG_CXX'
 /usr/share/automake-1.16/am/depend2.am: to 'configure.ac' and run 
 'aclocal' and 'autoconf' again
 src/Makefile.am: error: C++ source seen but 'CXX' is undefined
 src/Makefile.am: The usual way to define 'CXX' is to add 'AC_PROG_CXX'
 src/Makefile.am: to 'configure.ac' and run 'autoconf' again.
 src/Makefile.am:11: warning: variable 'NOPLUGIN_LDFLAGS' is defined but no 
 program or
 src/Makef

Re: [solved] managesieve configuration

2019-01-14 Thread Dominik Menke

On 1/13/19 12:23 PM, Stephan Bosch wrote:
With ssl=yes, the TLS layer is enabled immediately on the connection. 



Again, that's not what the documentation says:

ssl=yes [...]: SSL/TLS is offered to the client, but the client
isn't required to use it.

If the client is not _required_ to use it, it _may_ chose plaintext 
transport, no?


(I'm not here to argue, I'm just pointing out an issue with the wiki).


--Dominik


Re: [FTS Xapian] Beta release

2019-01-14 Thread Joan Moreau via dovecot
THank you Odhiambo. I updated accordingly 


On 2019-01-14 08:07, Odhiambo Washington wrote:

In your README.md, perhaps "This project intends to provide a straightforward and simple PROCEDURE to configure FTS plugin for Dovecot, leveraging the efforts by the Xapian.org team." is better?? 
Also in the part after cloning from git: 

./configure --prefix=/usr --with-dovecot=/path/to/dovecot [ This /path/to/dovecot is not obvious. Is it the dovecot binary or what??] 

On Mon, 14 Jan 2019 at 09:42, Joan Moreau via dovecot  wrote: 

Thank you Stephan. 

The version here shall be up and running : https://github.com/grosjo/fts-xapian 

On 2019-01-14 00:07, Stephan Bosch wrote: 

Op 13/01/2019 om 21:25 schreef Joan Moreau via dovecot: 
I tried to combined it, the "autoreconf" errors are solved


Now, when I type "make install", the lib is not pushed into dovecot folder, but 
somewhere in /usr/local/...

How to adjust this to have it arriving in the proper folder ?

Depends on your system. It mostly a matter of setting a proper --prefix 
directory for configure, but other paths are configurable as well. I usually 
check what the official distribution package for Dovecot is doing and use that 
as a basis.

For Debian I use the following configure command:

./configure --with-ldap=plugin --with-ssl=openssl --with-sql=plugin 
--with-lua=plugin --with-pgsql --with-mysql --with-sqlite \
--with-gssapi=plugin --with-solr --with-ioloop=best --enable-maintainer-mode \
--prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var 
--mandir=/usr/share/man \
--infodir=/usr/share/info --with-moduledir=/usr/lib/dovecot/modules 
--disable-rpath --disable-static

Regards,

Stephan

On 2019-01-13 21:01, Tuomi, Aki wrote:

You copied your Makefile.am there. Stephan made you a working version, can you 
try that?
(sorry for dup)
Aki
 Original message 
From: Joan Moreau 
Date: 13/01/2019 21:39 (GMT+02:00)
To: Stephan Bosch 
Cc: Aki Tuomi 
Subject: Re: [FTS Xapian] Beta release

I used the skeleton from Aki : https://github.com/grosjo/fts-xapian

However, when I try to act as a visitor, I reach teh follwoing error:

# autoreconf -vi
autoreconf: Entering directory `.'
autoreconf: configure.ac [1]: not using Gettext
autoreconf: running: aclocal -I m4
autoreconf: configure.ac [1]: tracing
autoreconf: running: libtoolize --copy
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf
autoreconf: running: /usr/bin/autoheader
autoreconf: running: automake --add-missing --copy --no-force
configure.ac:9 [2]: installing './compile'
configure.ac:11 [3]: installing './config.guess'
configure.ac:11 [3]: installing './config.sub'
configure.ac:7 [4]: installing './install-sh'
configure.ac:7 [4]: installing './missing'
src/Makefile.am: installing './depcomp'
/usr/share/automake-1.16/am/depend2.am [5]: error: am__fastdepCXX does not 
appear in AM_CONDITIONAL
/usr/share/automake-1.16/am/depend2.am [5]: The usual way to define 
'am__fastdepCXX' is to add 'AC_PROG_CXX'
/usr/share/automake-1.16/am/depend2.am [5]: to 'configure.ac [1]' and run 
'aclocal' and 'autoconf' again
src/Makefile.am: error: C++ source seen but 'CXX' is undefined
src/Makefile.am: The usual way to define 'CXX' is to add 'AC_PROG_CXX'
src/Makefile.am: to 'configure.ac [1]' and run 'autoconf' again.
src/Makefile.am:11: warning: variable 'NOPLUGIN_LDFLAGS' is defined but no 
program or
src/Makefile.am:11: library has 'NOPLUGIN' as canonical name (possible typo)
autoreconf: automake failed with exit status: 1

On 2019-01-13 20:24, Stephan Bosch wrote:

Oh, right, a distribution tarball doesn't include some of the
necessary files for your repository like autogen.sh and
.gitignore. The attached tarball includes all those and is ready
for `git init`. The previous tarball was made with `make
distcheck` from this one.

Regards,

Stephan.

Op 13/01/2019 om 20:14 schreef Stephan Bosch:

Hi Joan,

Op 13/01/2019 om 19:03 schreef Aki Tuomi:

Yes, from compiling point of view it is done.

Unfortunately what is not done is all the other work
involved, such as fixing all the inevitable bugs it has
and maintaining it. We do not want, at this moment, take
up maintaining and developing yet another FTS plugin as
we have plenty of things to do already.

I invite you to setup your own repository and provide
this plugin from there, being the maintainer of this
plugin. We can add a link to your plugin on our FTS page
so people can also find it.

There are other plugins like this, e.g.
https://github.com/st3fan/dovecot-xaps-plugin

I turned the code you provided into a separate plugin
package. The distribution tarball is attached.

N

RE: Re: segfault imaptest

2019-01-14 Thread Marc Roos
 

You should publish changelogs/issues or so, that would prevent somewhat 
reporting bugs twice. 

This version has problems with writing the messages to a mailbox in a 
namespace (stalls).
imaptest-20170719-1.fc27.x86_64



Please, unsubscribe me.
I really don't want to read this.

12.01.2019 22:47, Stephan Bosch пишет:
>
> Op 11/01/2019 om 15:13 schreef Marc Roos:
>> imaptest host=mail04.local port=143 user=xxx pass=xxx mbox=test.mbox
>>
>> [Fri Jan 11 15:09:14 2019] imaptest[7634]: segfault at 1354ff0 ip 
>> 01354ff0 sp 7ffed5d8f558 error 15 [Fri Jan 11 15:09:22 
>> 2019] imaptest[7635]: segfault at 2267ff0 ip 02267ff0 sp 
>> 7ffee5890308 error 15 [Fri Jan 11 15:10:47 2019] imaptest[7648]: 
>> segfault at 10e6ff0 ip 010e6ff0 sp 7ffedbb19f98 error 15
>>
>> CentOS Linux release 7.6.1810 (Core)
>> imaptest-20151005-1.el7.x86_64
>> Linux test2 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC
>> 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> That imaptest is from several years ago. I'd say this problem is 
> likely fixed. You can check with a newer version (compile one). And 
> for bug reports like this we need to have a gdb backtrace (e.g. run it 

> in gdb --args  and issue 'bt full' once it fails).
>
> Regards,
>
> Stephan.
>
>
> .
>