Lucene

[Joan Moreau]

Hi,

I can not get rid of the below message and my FTS seems not working 
properly. Is there a compile parameter to adjust to have Lucene working ?


doveadm(root): Debug: Skipping module doveadm_fts_lucene_plugin, because 
dlopen() failed: 
/usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_lucene_plugin.so: undefined 
symbol: lucene_index_iter_deinit (this is usually intentional, so just ignore 
this message)
doveadm(root): Debug: Skipping module doveadm_fts_plugin, because dlopen() 
failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: undefined 
symbol: fts_backend_rescan (this is usually intentional, so just ignore this 
message)

Thank you very much

Re: doveadm ssl error when upgrading from 2.2.27 to 2.2.29

[Pallissard, Matthew]

On Thu, Jun 08, 2017 at 11:06:01AM +0300, Aki Tuomi wrote:
> 
> 
> On 07.06.2017 15:16, Pallissard, Matthew wrote:
> > I'm starting to see the following error when upgrading from 2.2.27 to 
> > 2.2.29.
> >
> > doveadm(ip.add.re.ss): Error: doveadm client disconnected before handshake: 
> > SSL_accept() failed: error:1417A0C1:SSL 
> > routines:tls_post_process_client_hello:no shared cipher
> >
> > Downgrading from 2.2.27 resolves, error still persists in 2.2.28.
> >
> > I'm using openssl 1.1.0.f and an ec cert/key with the following curve.
> >   ASN1 OID: prime256v1
> >   NIST CURVE: P-256
> >
> >
> > Does anyone know anything about this off the top of their head? If not I'll 
> > try to git-bisect 2.2.27 -> 2.2.28 and see if I can find any offending 
> > commits later on this week.
> >
> 
> That would indicate a problem with cipher lists. What are you doing that
> causes this?
> 
> Aki

I'm dealing with a pretty vanilla config. 


The only ssl related settings are as follows.

ssl_cert= From the host where mail is being replicated to;
doveadm: Debug: SSL: elliptic curve prime256v1 will be used for ECDH and ECDHE 
key exchanges
doveadm(replicating.to.this.host): Debug: SSL: where=0x10, ret=1: before SSL 
initialization
doveadm(replicating.to.this.host): Debug: SSL: where=0x2001, ret=1: before SSL 
initialization
doveadm(replicating.to.this.host): Debug: SSL: where=0x2002, ret=-1: before SSL 
initialization
doveadm(replicating.to.this.host): Debug: SSL: where=0x2002, ret=-1: before SSL 
initialization
doveadm(replicating.to.this.host): Debug: SSL: where=0x2001, ret=1: before SSL 
initialization
doveadm(replicating.to.this.host): Debug: SSL alert: where=0x4008, ret=552: 
fatal handshake failure
doveadm(replicating.to.this.host): Debug: SSL: where=0x2002, ret=-1: error
doveadm(replicating.to.this.host): Debug: SSL error: SSL_accept() failed: 
error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
doveadm(replicating.to.this.host): Error: doveadm client disconnected before 
handshake: SSL_accept() failed: error:1417A0C1:SSL 
routines:tls_post_process_client_hello:no shared cipher
doveadm(replicating.to.this.host): Debug: SSL error: SSL_accept() syscall 
failed: Invalid argument

>From the host where the mail is being replicated from.
dovecot[5904]: doveadm(m...@pallissard.net): Error: doveadm server disconnected 
before handshake: Broken pipe
dovecot[5904]: doveadm(m...@pallissard.net): Error: sync: Disconnected from 
remote: Broken pipe

-- 
Matt Pallissard

Minor patches for builds against ancient platforms

[M. Balridge]

I was recently asked to upgrade some neolithic aged software (UW-IMAP,
sendmail 8.12.x, apache 1.3, amongst other horrors).

The box is physically remote, so an aggressive "new flush" wasn't an option. 
I've been able to upgrade the compiler to gcc-3.4, openssl to 1.0.2k, glibc,
php to something in the 5.4-branch, etc.

I have CLucene working, even.

I know should take a shotgun to the box and retire it. It's a NORTHWOOD P4, no
less, with only 1.5GB RAM and 74GB of SCSI-160 storage.

*BUT* that isn't my call to make, as much as I'd like to do the right thing.

When Life(tm) hands you incredibly sour and bitter oranges, the best you can
do aside from making a Palmetto Punch, is perhaps traditional Cochinita pibil
the way they do in the Yucatan.

I ran across two main problems, the first of which struck during the build.

Amazingly enough, I was able to update pcre, gettext, openssl, textcat, and
other libraries to modern versions without too much pain and suffering.

1) In src/lib/compat.h there is a definition for p(read|write) that conflicts
with the one in /usr/include/unistd.h

On this box, there is a macro appended to the definition (to control whether
or not THROW is defined in C++ "mode").  This is regulated by using the macro
__THROW.  I assume this is anachronistic.

2) There was an odd overflow bug in the quota module. (Yes, would you believe
that user quotas are used + enforced on this Frankenbox?)  I assume it's a
rarely seen issue because few Dovecot users compile the software in caves on
computers powered by horse-pulled generator wheels.  I suspect Timo's seen
more Abominable Snowcreatures in Espoo than systems like these.

Simply adding an explicit 64 bit (unsigned) type to the constant multipliers
seemed to address this. Of these two patches, this is probably the most "safe"
and thus likely to be accepted into the main branch of code.

Thanks for the great software, as always, Timo. It's a testimony to your
design and implementation acumen that software you've written in 2017 still
runs on machines that went obsolete in 480 B.C.E.

I am trying to track down one possible issue that could be locking-related,
which causes some mailbox open operations to see to take longer than they
should. Log entries like:

> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
> was locked for 95 seconds (rotating while syncing)

> Warning: Transaction log file /home/luser/mail/.imap/INBOX/dovecot.index.log
> was locked for 92 seconds (rotating while syncing)

I am using sendmail 8.15.2 (HASFLOCK not defined) and procmail 3.22 (Locking
strategies: dotlocking, fcntl(), lockf(), flock())

I also see odd errors while using SeaMonkey clients:

imap(luser): Error: fchown(/home/luser/mail/.subscriptions.lock,
group=501(coregroup)) failed: Operation not permitted (egid=200(users), group
based on /home/luser/mail - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)

imap(luser): Error: file_dotlock_open() failed with subscription file
/home/luser/mail/.subscriptions: Operation not permitted

.subscriptions doesn't exist either as a file or a directory in the named
directories.

Is there a "filter" against dot-files being opened within the bowels of dovecot?

Onto the "meat" of this "bug" report:

Dovecot: dovecot-2.2.30.2 
Slackware 9 (with most of the core libs upgraded to the latest possible)
Kernel: 2.4.35-ow2

Configure command: CC=gcc-3.4 CXX=g++-3.4 \
CFLAGS='-O2 -march=pentium4 -mtune=pentium4 -fPIC -fPIE \
 -fomit-frame-pointer -fstack-protector-all -D_FORTIFY_SOURCE=2' \
CFLAGS='-O2 -march=pentium4 -mtune=pentium4 -fPIC -fPIE \
 -fomit-frame-pointer -fstack-protector-all -D_FORTIFY_SOURCE=2' \
CPPFLAGS=-I/dev/shm/libstemmer_c/include \
LDFLAGS='-L/dev/shm/libstemmer_c -z relro -z now' \
./configure --prefix=/usr --with-ssldir=/etc/ssl --localstatedir=/var \
--sysconfdir=/etc/dovecot --with-bzlib --with-libcap --with-lz4 \
--with-textcat --with-stemmer --with-sql=yes --with-cdb \
--with-shadow --with-libwrap --with-moduledir=/usr/lib/dovecot \
--with-icu --with-lucene --with-sqlite --with-sql=yes

Build fix patch (mismatching prototype): https://pastebin.com/GS3a2DPX
Quota Overflow Fix Patch: https://pastebin.com/gsSXmkz9

Dovecot configuration: https://pastebin.com/JX43feFw

Without the patch:

# doveadm quota get -u luser
Quota name  Type  Value   Limit%
User quota  STORAGE 3365836 1305696  257
Group quota STORAGE   0   -0

(All attempts to add mail to any folder fail with a quota error.)

With the patch:

# doveadm quota get -u luser
Quota name  Type  Value   Limit %
User quota  STORAGE 3364608 55061
Group quota STORAGE   0   - 0

Thanks,
=M=

Re: lmtp: Error: Temp file creation to /tmp/ ... failed: No such file or directory on incoming mails with attachments

[Lars-Sören Steck]

Dear Aki,


as far as I know, I'm not using chroot. I am not aware of any setting
within my dovecot configuration that I attached which enables this. I
checked my mysql database as well (as it is stated in the dovecot
documentation that a chroot can also be returned by userdb), but it is
not activated there as well.

Also, I am using Apparmor and it is logging blocks to kern.log, where I
can't find anything related to this issue.

What I can notice is that this issue only happens randomly and once it
happened, it will continue to happen until dovecot is restarted. Then
only mails with attachments are stuck in mailqueue. I can't reproduce
it, even if I want to. I just sent a mail with a 25 MB attachment to an
address and it wasn't a problem. I can see from my logfiles though, that
this issue has happened several times already.


Lars


Am 08.06.2017 um 10:09 schrieb Aki Tuomi:
>
> On 07.06.2017 23:42, Lars-Sören Steck wrote:
>> Dear list,
>>
>> I'm currently facing problems when receiving eMails with attachments, at
>> least sometimes.
>>
>> My mailserver is set up with the tool 'Mailcow', and hence is based on
>> Dovecot (2.2.22 (fe789d2)) and Postfix.
>>
>> Usually, there are no problems with receiving mails. If a mail has an
>> attachment, however, it is possible that the following error occurs
>> (extract from /var/log/mail.log):
>>
>> 'Jun  7 12:50:28 mail postfix/lmtp[26827]: 564E68A0515:
>> to=, relay=my.mail.server[private/dovecot-lmtp],
>> delay=0.71, delays=0.67/0.01/0.01/0.02, dsn=4.3.0, status=deferred (host
>> my.mail.server[private/dovecot-lmtp] said: 451 4.3.0 Temporary internal
>> failure (in reply to end of DATA command))'
>>
>> Extract from /var/log/mail.err:
>>
>> 'Jun  7 12:50:28 mail dovecot: lmtp(26828): Error: Temp file creation to
>> /tmp/dovecot.lmtp.mail.26828. failed: No such file or directory'
>>
>>
>> Once this happened the first time after dovecot is running, it will
>> happen for all incoming mails with attachments. This can be solved
>> temporarily by restarting the dovecot service and running postqueue -f,
>> but that obviously does not solve the underlying problem.
>>
>> In this post to this list, it is stated that dovecot sometimes creates
>> temp files to avoid 'excessive memory usage'. I'm guessing that this is
>> the case here, also the error message is similiar:
>>
>> https://dovecot.org/list/dovecot/2016-June/104722.html
>>
>>
>> Should I simply change the configuration variable mail_temp_dir to solve
>> this? Why is dovecot not able to find the /tmp folder? In the list
>> thread, it is stated that this is caused by dovecot running with enabled
>> chrooting. As far as I understand it though (correct me if I'm wrong),
>> chrooting is not enabled in my dovecot configuration.
>>
>> Please find attached the output of 'dovecot -n':
>>
>>
> Are you using either chroot or some apparmor/selinux/whatever security
> suite which is preventing writing to /tmp?
>
> Aki

pigeonhole: imapsieve: AntiSpam example

[Larry Rosenman]

Is there a reason why vnd.dovecot.execute is called out for 
sieve_global_extensions
but no configuration or require is there for it on:
https://wiki.dovecot.org/HowTo/AntispamWithSieve

thanks!
-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: larry...@gmail.com
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

Re: Any documentation around timeout states ?

[Joseph Tam]

Hi, this has been fixed in more recent release, where the states are
converted to human readable strings, see

https://git.dovecot.net/dovecot/core/commit/e7d9dd003e6192b294507b9fbe9917a514e441f6


Internal name I guess.  For the rest of us:

https://github.com/dovecot/core/commit/e7d9dd003e6192b294507b9fbe9917a514e441f6

Joseph Tam 

Re: Dovecot login is slow

[Aki Tuomi]

Can you try adding blocking=yes to your dovecot-ldap.conf.ext

Aki

On 08.06.2017 11:15, Mitocariu Emilian wrote:
> No, other servers use the same LDAP and the response is fast. The
> weird part is that this morning i played a little with the
> configuration, but in the end i came back to the settings i had
> previously and now it works better, but from time to time it still
> hangs a little
>
> On Thu, Jun 8, 2017 at 11:07 AM, Aki Tuomi  > wrote:
>
>
>
> On 07.06.2017 16:34, Mitocariu Emilian wrote:
> > Hi,
> >
> > I have an Ubuntu 16.04 server with dovecot 2.2.22 configured as
> an imap
> > server with an LDAP backend for authentication. This is the
> output of
> > "dovecot -n":
> > # 2.2.22 (fe789d2): /etc/dovecot/dovecot.conf
> > The problem i'm having is that when i try to login it takes more than 10
> > seconds, making my webmail very slow. For testing i login to
> imap like this
> > "openssl s_client -connect localhost:993" and sometimes i get
> this message
> > "* OK Waiting for authentication master process to respond..". I
> saw at
> > other people, one of the problem was because they didn't
> disabled pam
> > authentication when using another backend (like ldap or sql),
> but i already
> > did that.
> >
> > Does anyone know what could cause such long login times and how
> to fix it?
>
> Does your LDAP take long time to respond?
>
> Aki
>
>

Re: mail storage auto detection failed?

[Aki Tuomi]

You are missing mail_location, the actual value is dependent on your
filesystem structure and used mail driver

Example:

mail_location = maildir:~/Maildir

Aki

On 08.06.2017 11:11, Alef Veld wrote:
> Hi everyone. Nice to meet you.
>
> I’m new to dovecot and i came across a problem it seems.
>
> I setup a new user called sales with useradd, and gave it a password. 
> Although it has a home directory, i set login to /sbin/nologin.
>
> When logging into the pop server on port 110 (with telnet) i get this in the 
> logs:
>
> dovecot: pop3-login: Login: user=, method=PLAIN, rip=127.0.0.1,   
> lip=127.0.0.1, mpid=12938, secured, session=<94SotWVRoAB/AAAB>
> Jun  7 21:49:24 www dovecot: pop3(sales): Error: user sales: Initialization 
> failed: Namespace '': Mail storage autodetection failed with home=/home/sales
> Jun  7 21:49:24 www dovecot: pop3(sales): Error: Invalid user settings. Refer 
> to server log for more information.
>
>
> Did i have to initialise the mailbox in the homedirectory? What did i forget. 
> I didn't change anything to the default dovecot.conf, i just installed the 
> package with yum install dovecot (so latest version). This error also shows 
> up when logging into port 143. Thanks for your help.
>
> My dovecot -n output if that helps is :
> [ec2-user@www log]$ dovecot -n
> # 2.2.10: /etc/dovecot/dovecot.conf
> # OS: Linux 4.9.20-10.30.amzn1.x86_64 x86_64
> mbox_write_locks = fcntl
> namespace inbox {
>   inbox = yes
>   location =
>   prefix =
> }
> passdb {
>   driver = pam
> }
> ssl = required
> ssl_cert =  ssl_key =  ssl_protocols = !SSLv2 !SSLv3
> userdb {
>   driver = passwd
> }
>
> Thanks a lot.
> -atv

Re: Any documentation around timeout states ?

[Aki Tuomi]

On 08.06.2017 04:28, Matt Bryant wrote:
> Been seeing a number of proxy timouts recently with errors such as ...
>
> timed out in state=4
> timed out in state=2
>
> Is there any doco around what state 2/4 actually means ... atm got
> auth_debug on to see if we can track further information down
>
> centos 7 x86_64
> dovecot 2.2.19
>
> rgds
>
> Matt

Hi, this has been fixed in more recent release, where the states are
converted to human readable strings, see

https://git.dovecot.net/dovecot/core/commit/e7d9dd003e6192b294507b9fbe9917a514e441f6

Aki

mail storage auto detection failed?

[Alef Veld]

Hi everyone. Nice to meet you.

I’m new to dovecot and i came across a problem it seems.

I setup a new user called sales with useradd, and gave it a password. Although 
it has a home directory, i set login to /sbin/nologin.

When logging into the pop server on port 110 (with telnet) i get this in the 
logs:

dovecot: pop3-login: Login: user=, method=PLAIN, rip=127.0.0.1,   
lip=127.0.0.1, mpid=12938, secured, session=<94SotWVRoAB/AAAB>
Jun  7 21:49:24 www dovecot: pop3(sales): Error: user sales: Initialization 
failed: Namespace '': Mail storage autodetection failed with home=/home/sales
Jun  7 21:49:24 www dovecot: pop3(sales): Error: Invalid user settings. Refer 
to server log for more information.


Did i have to initialise the mailbox in the homedirectory? What did i forget. I 
didn't change anything to the default dovecot.conf, i just installed the 
package with yum install dovecot (so latest version). This error also shows up 
when logging into port 143. Thanks for your help.

My dovecot -n output if that helps is :
[ec2-user@www log]$ dovecot -n
# 2.2.10: /etc/dovecot/dovecot.conf
# OS: Linux 4.9.20-10.30.amzn1.x86_64 x86_64
mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
  location =
  prefix =
}
passdb {
  driver = pam
}
ssl = required
ssl_cert = 

Re: lmtp: Error: Temp file creation to /tmp/ ... failed: No such file or directory on incoming mails with attachments

[Aki Tuomi]

On 07.06.2017 23:42, Lars-Sören Steck wrote:
> Dear list,
>
> I'm currently facing problems when receiving eMails with attachments, at
> least sometimes.
>
> My mailserver is set up with the tool 'Mailcow', and hence is based on
> Dovecot (2.2.22 (fe789d2)) and Postfix.
>
> Usually, there are no problems with receiving mails. If a mail has an
> attachment, however, it is possible that the following error occurs
> (extract from /var/log/mail.log):
>
> 'Jun  7 12:50:28 mail postfix/lmtp[26827]: 564E68A0515:
> to=, relay=my.mail.server[private/dovecot-lmtp],
> delay=0.71, delays=0.67/0.01/0.01/0.02, dsn=4.3.0, status=deferred (host
> my.mail.server[private/dovecot-lmtp] said: 451 4.3.0 Temporary internal
> failure (in reply to end of DATA command))'
>
> Extract from /var/log/mail.err:
>
> 'Jun  7 12:50:28 mail dovecot: lmtp(26828): Error: Temp file creation to
> /tmp/dovecot.lmtp.mail.26828. failed: No such file or directory'
>
>
> Once this happened the first time after dovecot is running, it will
> happen for all incoming mails with attachments. This can be solved
> temporarily by restarting the dovecot service and running postqueue -f,
> but that obviously does not solve the underlying problem.
>
> In this post to this list, it is stated that dovecot sometimes creates
> temp files to avoid 'excessive memory usage'. I'm guessing that this is
> the case here, also the error message is similiar:
>
> https://dovecot.org/list/dovecot/2016-June/104722.html
>
>
> Should I simply change the configuration variable mail_temp_dir to solve
> this? Why is dovecot not able to find the /tmp folder? In the list
> thread, it is stated that this is caused by dovecot running with enabled
> chrooting. As far as I understand it though (correct me if I'm wrong),
> chrooting is not enabled in my dovecot configuration.
>
> Please find attached the output of 'dovecot -n':
>
>

Are you using either chroot or some apparmor/selinux/whatever security
suite which is preventing writing to /tmp?

Aki

Re: Dovecot login is slow

[Aki Tuomi]

On 07.06.2017 16:34, Mitocariu Emilian wrote:
> Hi,
>
> I have an Ubuntu 16.04 server with dovecot 2.2.22 configured as an imap
> server with an LDAP backend for authentication. This is the output of
> "dovecot -n":
> # 2.2.22 (fe789d2): /etc/dovecot/dovecot.conf
> The problem i'm having is that when i try to login it takes more than 10
> seconds, making my webmail very slow. For testing i login to imap like this
> "openssl s_client -connect localhost:993" and sometimes i get this message
> "* OK Waiting for authentication master process to respond..". I saw at
> other people, one of the problem was because they didn't disabled pam
> authentication when using another backend (like ldap or sql), but i already
> did that.
>
> Does anyone know what could cause such long login times and how to fix it?

Does your LDAP take long time to respond?

Aki

Re: doveadm ssl error when upgrading from 2.2.27 to 2.2.29

[Aki Tuomi]

On 07.06.2017 15:16, Pallissard, Matthew wrote:
> I'm starting to see the following error when upgrading from 2.2.27 to 2.2.29.
>
> doveadm(ip.add.re.ss): Error: doveadm client disconnected before handshake: 
> SSL_accept() failed: error:1417A0C1:SSL 
> routines:tls_post_process_client_hello:no shared cipher
>
> Downgrading from 2.2.27 resolves, error still persists in 2.2.28.
>
> I'm using openssl 1.1.0.f and an ec cert/key with the following curve.
>   ASN1 OID: prime256v1
>   NIST CURVE: P-256
>
>
> Does anyone know anything about this off the top of their head? If not I'll 
> try to git-bisect 2.2.27 -> 2.2.28 and see if I can find any offending 
> commits later on this week.
>

That would indicate a problem with cipher lists. What are you doing that
causes this?

Aki

Segmentation fault in imap_bodystructure_is_plain_7bit

[mihaiush]

Hi,

I have a lot of errors like this in my log:
Fatal: master: service(imap): child 26049 killed with signal 11 (core
dumped)

Dovecot 2.2.18 build from sources ./configure --prefix=/opt/dovecot2
--with-mysql --with-sqlite --with-solr --with-ssl --disable-rpath
--disable-static.
Debian Wheezy 3.2.63-2 x86_64.
Filesystem is ZFS.

All the core files are similar:
$ gdb /opt/dovecot2/libexec/dovecot/imap core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /opt/dovecot2/libexec/dovecot/imap...done.
[New LWP 11635]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/opt/dovecot2/libexec/dovecot/imap imap-postlogin'.
Program terminated with signal 11, Segmentation fault.
#0  imap_bodystructure_is_plain_7bit (part=part@entry=0x234cd50) at
imap-bodystructure.c:458

458if (data->content_subtype != NULL &&
(gdb) bt
#0  imap_bodystructure_is_plain_7bit (part=part@entry=0x234cd50) at
imap-bodystructure.c:458
#1  0x7f920a0fbfaf in index_mail_body_parsed_cache_flags
(mail=0x234be60) at index-mail.c:587
#2  index_mail_parse_body_finish (mail=mail@entry=0x234be60,
field=field@entry=MAIL_CACHE_IMAP_BODYSTRUCTURE, success=success@entry=true)
at index-mail.c:1007
#3  0x7f920a0fc369 in index_mail_parse_body (mail=mail@entry=0x234be60,
field=field@entry=MAIL_CACHE_IMAP_BODYSTRUCTURE) at index-mail.c:1081
#4  0x7f920a0fc498 in index_mail_parse_bodystructure
(mail=mail@entry=0x234be60,
field=field@entry=MAIL_CACHE_IMAP_BODYSTRUCTURE) at index-mail.c:1222
#5  0x7f920a0fcf1c in index_mail_get_special (_mail=_mail@entry=0x234be60,
field=field@entry=MAIL_FETCH_IMAP_BODYSTRUCTURE,
value_r=value_r@entry=0x7ffc1518fde8)
at index-mail.c:1379
#6  0x7f920a0b29cd in dbox_mail_get_special (_mail=_mail@entry=0x234be60,
field=field@entry=MAIL_FETCH_IMAP_BODYSTRUCTURE,
value_r=value_r@entry=0x7ffc1518fde8)
at dbox-mail.c:229
#7  0x7f920a0a83f0 in mdbox_mail_get_special (_mail=0x234be60,
field=MAIL_FETCH_IMAP_BODYSTRUCTURE, value_r=0x7ffc1518fde8) at
mdbox-mail.c:213
#8  0x7f920a08f96d in mail_get_special (mail=,
field=field@entry=MAIL_FETCH_IMAP_BODYSTRUCTURE,
value_r=value_r@entry=0x7ffc1518fde8)
at mail.c:317
#9  0x00419a6a in fetch_bodystructure (ctx=0x232bbd8,
mail=, context=) at imap-fetch.c:690
#10 0x00419f9f in imap_fetch_more_int (ctx=ctx@entry=0x232bbd8,
cancel=false) at imap-fetch.c:506
#11 0x0041af07 in imap_fetch_more (ctx=0x232bbd8,
cmd=cmd@entry=0x232ba00)
at imap-fetch.c:558
#12 0x0040f0c9 in cmd_fetch (cmd=0x232ba00) at cmd-fetch.c:286
#13 0x00418aec in command_exec (cmd=cmd@entry=0x232ba00) at
imap-commands.c:167
#14 0x00417ad0 in client_command_input (cmd=cmd@entry=0x232ba00) at
imap-client.c:814
#15 0x00417b64 in client_command_input (cmd=0x232ba00) at
imap-client.c:874
#16 0x00417e45 in client_handle_next_command
(remove_io_r=, client=0x232ade0) at imap-client.c:912
#17 client_handle_input (client=client@entry=0x232ade0) at imap-client.c:924
#18 0x00418212 in client_input (client=0x232ade0) at
imap-client.c:966
#19 0x7f9209df134b in io_loop_call_io (io=0x232b8f0) at ioloop.c:501
#20 0x7f9209df1e5b in io_loop_handler_run_internal
(ioloop=ioloop@entry=0x22ec790)
at ioloop-epoll.c:220
#21 0x7f9209df13d9 in io_loop_handler_run (ioloop=ioloop@entry=0x22ec790)
at ioloop.c:548
#22 0x7f9209df1458 in io_loop_run (ioloop=0x22ec790) at ioloop.c:525
#23 0x7f9209d92993 in master_service_run (service=0x22ec620,
callback=callback@entry=0x421140 ) at master-service.c:581
#24 0x0040c60b in main (argc=2, argv=0x22ec390) at main.c:431
(gdb) q

I wrote a patch which solved the problem but:
- my C is absolutely basic,
- dovecot is already at version 2.2.30, maybe problem was already fixed.
Anyway I attached my patch, please have a look.

Thanks.
--- a/src/lib-imap/imap-bodystructure.c	2015-01-05 21:20:07.0 +0100
+++ b/src/lib-imap/imap-bodystructure.c	2016-12-08 13:31:07.302354497 +0100
@@ -20,6 +20,8 @@
 
 #define NVL(str, nullstr) ((str) != NULL ? (str) : (nullstr))
 
+const struct message_part_body_data null_mpbd = {0};
+
 static char *imap_get_string(pool_t pool, const char *value)
 {
 	string_t *str = t_str_new(64);
@@ -325,6 +327,9 @@
 {
 	struct message_part_body_data *data = part->context;
 
+	if (data == NULL)
+data = &null_mpbd;
+
 	if (part->children != NULL)
 		imap_bodystructure_write_sibli