Re: Virus scan + removal on a mdbox mail storage

[Christoph Haas via dovecot]

Hello David,

- Nachricht von David Pottage via dovecot  -
 Datum: Thu, 21 Feb 2019 13:58:14 +
   Von: David Pottage via dovecot 
Antwort an: David Pottage 
   Betreff: Re: Virus scan + removal on a mdbox mail storage
An: dovecot@dovecot.org


[...]

NO! My mail storage is mdbox. And at the moment I have no intention to
convert it to Maildir!

Could I ask why? maildir is a better storage format is almost every respect.


well, I have a mailbox with about 50k emails ..., so one reason seems  
to me better backup performance with mdbox, since there are much less  
files to save.


Another reason - you can beat me for this - it's more freaky ;-) - no,  
just kidding ...
There was some years ago an interesting lecture from Peer Heinlein  
about the mdbox mail storage, I afterwards bought his "Dovecot Buch"  
of OpenSource Press and sticked to mdbox.


But I'll test backup of my mail storage converted to Maildir (which  
can easily be done thanks dsync)

- If there are no significant time difference, I might then change to Maildir.

[...]
The thing is that users will usually open emails shortly after they  
arrive. Most emails are not opened again later, especially the  
attachments.


you're right about this. And if a user has suspicions abaout a  
possibly infected attachment, one can delete the whole email without  
hassle.


[...]
For my day job I work for Sophos (A cyber security vendor), so all  
this is familiar to me. If you have the budget for a commercial  
product, then Sophos PureMessage does have postfix support.  
Technical details here:


https://docs.sophos.com/msg/pmx/help/en-us/msg/pmx/tasks/GSGConfigExtPostfixConfig.html

Other AV vendors probably have similar support, but I don't know any details.

--
David Pottage


I know about Sophos. Since my infrastructure is only for me and my  
family, I'll use the SAV9-free package ... and will try to integrate  
this with Postfix or AmaVisd.


- Ende der Nachricht von David Pottage via dovecot  
 -


Christoph.

--
Christoph Haas


bin_ijLLkhTCE.bin
Description: Öffentlicher PGP-Schlüssel


pgploURl1Izxg.pgp
Description: Digitale PGP-Signatur

Re: index problems after update

[Adi Pircalabu via dovecot]

On 2019-02-21 22:18, Sami Ketola via dovecot wrote:
On 21 Feb 2019, at 12.23, Hajo Locke via dovecot  
wrote:
I think mbox+procmail is a classic setup and wide used and good 
solution for many usecases. Same setup we use many years.
We run ~2 mio mailboxes. our automated systems depends on this setup. 
creating mailboxes, managing mailboxes, creating automated 
filterrules, backupsystem to tell something of them. we can not switch 
our whole mailsetup to work around this bug.
How to get a dump if dovecot not crashing but has wrong behaviour? I 
would like to help and provide useful info, but it depends on kind of 
problem.
I think if a classic setup is not working in dovecot any more, this is 
a serious problem.


In you first email to this thread it says:

Feb  8 08:45:37 hostname dovecot[14882]: imap(myuser): Fatal: master: 
service(imap): child 14135 killed with signal 6 (core dumped)


So imap is crashing and even dumping a core.

Also I must disagree with your mbox+procmail statement. mbox has
always been very unoptimised mailbox format and everyone should be
emphasised not to use it.
Also that combination has always had problems with indexing and file
locking. I would not use it on high volume mailservers. Or even medium
volume mailservers.


Not directly affected by this issue since I'm not using mbox for any 
production system nor have I for many years. And it'd take a lot of 
effort to convince me to use mbox for anything someone would even dare 
to classify, even remotely, as "production". But if I understand OP's 
point of view correctly, he's not arguing necessarily for or against a 
specific mailbox format. Instead, he's flagging a regression and people 
will be very reluctant to upgrade or even adopt a certain feature in a 
new release of a product if regressions are seen as acceptable. 
Something that previously worked in an otherwise unchanged environment 
stopped working after an upgrade and this is a regression. Trying to 
convince people to move away from mbox is a very sensible approach, I'm 
all for it, but in cases like this not practical.


--
Adi Pircalabu

Re: Assistance with doveadm backup...

[Joseph Tam via dovecot]

On Wed, 20 Feb 2019, SH Development wrote:


To: Joan Moreau via dovecot 


Jean did take over the list for a while when developing his FTS backend,
so you can be forgiven that he actually runs this list.


2.  It was also suggested to rsync the directory, but the question was
brought up, and not answered, about whether it was advisable to copy
live mail, thus the need for doveadm sync/backup.


You're right that consistency is a problem if you rsync a large amount of
changing data.  (If I remember correctly, mdbox is especially sensitive to
content/index mismatches.)

One way this can be done is via filesystem magic i.e. filesystems with
copy-on-write that allow you to take a moment in time snapshot of your
entire filesystem e.g. LVM, ZFS and others.  You can then rsync the
snapshot, but some of these filesystem also support methods to export
snapshots to a remote filesystem.

Joseph Tam 

Authenticating with checkpassword

[Mark Foley via dovecot]

I am trying to use the checkpassword authentication 
(https://wiki.dovecot.org/AuthDatabase/CheckPassword)
I do have a working checkpassword program. The protocol expects to received on 
fd 3 the
following:

usernamepasswordoptionalstuff

I find that this works properly and the program can authenticate if the client 
is using PLAIN
LOGIN.  Both username and password are sent on fd3.  But, if the client has 
specified
kerberos/gssapi authentication then only the username is passed to 
checkpassword.  The
following is a debug dump from checkpassword showing the input read on fd 3 (12 
bytes):

len 12: 636861726d61696e6500 charmaine...
User: [charmaine], PW: []

Without a password, checkpassword returns failure. 

I am running dovecot in a Samba4 Active Directory.  I have some email clients 
that use
kerberos/GSSAPI (Thunderbird) and some that can only use PLAIN LOGIN (Outlook). 
 All users,
however, are active directory domain users and all could potentially 
authenticate with AD
credentials. 

I was hoping to use checkpassword for this. Otherwise, every user who cannot 
authenticate via
kerberos/GSSAPI has to also be in the mail server's /etc/passwd file with the 
same ID/PW as 
their AD credentials, which become a bit of a pain when the user changes his 
domain password.

Why does not dovecot pass to checkpassword the user's password? When I tried 
this a few years
ago I thought it did.

If checkpassword fails, why does it not then try the kerberos/GSSAPI mechanism?

Is there a solution to this? 

THX --Mark

Re: Virus scan + removal on a mdbox mail storage

[David Pottage via dovecot]

On 2019-02-20 19:02, Christoph Haas via dovecot wrote:

On 2019-02-20 01:46, Christoph Haas via dovecot wrote:

I need advice on how virus scan and removal can be done on a _mdbox_
mail storage?

On a maildir storage the virus scanner (e.g. clamav etc.) can detect
and remove a email that is infected, since every email and attachment
are stored in separate files.

But in mdbox the emails and attachments are compressed together in 
one

ore more mdbox-files ...

I am anxious to convert my mail storage for virus scanning into
maildir format, since I don't know if a virus or crypto trojan con be
activated with this converting action =:-o


To clarify: You want to convert your mail storage from mdbox to  
maildir, but you want to scan for viruses first?


NO! My mail storage is mdbox. And at the moment I have no intention to
 convert it to Maildir!

[snip]

Could I ask why? maildir is a better storage format is almost every 
respect.



You are doing things in the wrong order.

Firstly converting mail storage format is very unlikely to trigger a  
virus. For that to happen the virus author would need to find and  
write an exploit for dovecot that will trick it into treating email  
as executable code. While not impossible that is quite unlikely  
because there is no normal situation where dovecot will execute  email 
as code. Also it is unlikely that a virus writer will target  dovecot 
when Microsoft exchange is much more common and would be a  higher 
value target.


Secondly, as a rule you want to scan email for viruses as it arrives  
and leaves, not when it is at rest in user mailboxes, again it is  
possible that a new virus will be discovered some time after the  
email arrives so a retrospective scan would find it, but that won't  
help you much because most users read their email and open  
attachments soon after the email arrives.


I'm completely with you! I have of course configured my postfix with
Amavisd-new and all that stuff. But viruses evolve quite faster than
detection patterns of e.g. Clam-AV.

So it is likely, that Clam-AV didn't detect a virus when scanning the
mail-traffic on arrival and the malware now resides in the
mdbox-storage.

For this situation an afterward virus scan of the existing mail
storage on a regular basis seems to me an appropriate method to get
rid of viruses, trojans etc. that were not detected on arrival and
reside like a time bomb in my mail storage...


The thing is that users will usually open emails shortly after they 
arrive. Most emails are not opened again later, especially the 
attachments.


So if a virus laden email got through because the definitions for your 
anti-virus solution where not updated in time, then it is fairly likely 
that the user's desktop computer is now infected (the endpoint). To fix 
that risk, you need a traditional endpoint virus scanner. In the 
unlikely event that a user opens an attachment in an old email, then 
their endpoint security will also intervene and prevent an infection.


In other words, it all comes back to endpoint security. Without it you 
are very prone to a virus infection. Scanning incoming email is helpful 
to reduce noise and inconvenience, but it is not a substitute for 
endpoint security, as in any case users can be infected in plenty of 
other ways, such as booby trapped websites or infected USB keys that 
they bring into the office.



Btw.: what virus scanners besides Clam-AV are the people on this list
using? And how is the virus scanner implemented: via Amavisd-new or
e.g. rspamd or ...?
- I hope this question is not too offtopic for the dovecot list!


You are right, that is a little offtopic. It is realy a postfix 
question.


For my day job I work for Sophos (A cyber security vendor), so all this 
is familiar to me. If you have the budget for a commercial product, then 
Sophos PureMessage does have postfix support. Technical details here:


https://docs.sophos.com/msg/pmx/help/en-us/msg/pmx/tasks/GSGConfigExtPostfixConfig.html

Other AV vendors probably have similar support, but I don't know any 
details.


--
David Pottage

Re: index problems after update

[Gerald Galster via dovecot]

For replicated servers I'm stuck with 2.2.33.2 because of pop3/dsync problems,
but on single servers I have no index problems after upgrading to 
dovecot-2.2.35-1.el7.centos.0.x86_64
or dovecot-2.2.36-3.el7.x86_64.

All servers run CentOS 7 (RHEL 7) but use lmtp delivery with mdbox and sieve.
Maybe something in dovecot-lda has changed?

Best regards
Gerald

> Am 21.02.2019 um 14:12 schrieb Gonzalo Palacios Goicolea via dovecot 
> :
> 
> El 21/02/2019 a las 10:51, Aki Tuomi via dovecot escribió:
>> On 21.2.2019 10.53, Hajo Locke via dovecot wrote:
>>> Hello,
>>> 
>>> Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot:
> On 18 February 2019 09:28 Hajo Locke via dovecot
>   wrote:
> 
> 
> Hello,
> it seems we need a dovecot developers opinion. May be we hit a
> bug or cant help ourselves.
>
>>> Thanks for your answer.
 Core dump with backtrace would help, if possible to acquire. Please
 refer to https://dovecot.org/bugreport.html 
  for information how to
 get a core dump.
 
 Aki
 
>>> Unfortunately its hard to get a backtrace because dovecot is not
>>> crashing. so it seems to be more a kind of logic problem in code and
>>> no unexpected situation.
>>> yesterday evening i had next incident. I upgraded from 2.2.33.2 to
>>> 2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken
>>> index and delivers no new mails. it starts delivering if i delete
>>> index files. At this point i cant tell if 2.2.36.1 also has same bug
>>> and writes a damaged index, but very likely.  We dont know this
>>> problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on
>>> mbox-index code must happend which leads to this big problem. So imapd
>>> cant do what he was created for.
>>> 
>>> For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and
>>> will try this. In my opinion this is a major problem and i expect a
>>> lot of affected people with version > 2.2.22 and classic mbox-storage.
>>> 
>>> Thanks,
>>> Hajo
>> We consider mbox + procmail setup somewhat edge case, and if the core
>> dump does not point into something more generic, it will probably not
>> get fixed. It is more likely to have this working if you use
>> dovecot-lda/lmtp with sieve instead of procmail.
>> 
>> Aki
>> 
> Hi Aki, 
> In support of Hajo I've to say that a few days ago I posted a similar issue, 
> and I use dovecot-lda+sieve. My environment has RHEL6 and 7 servers. When I 
> last updated the servers RHEL6 servers mantained 2.2.10-1_14.el6.x86_64 
> version, while RHEL7 updated dovecot from 2.2.10-8.el7.x86_64 to 
> 2.2.36-3.el7.x86_64. When the RHEL7 servers (used for sympa) processed a 
> message for a user, its indexes were corrupted, and the user could't access 
> his inbox through webmail, so I had to delete dovecot.* files from the user 
> mail path to get it working again. 
> My solution was to downgrade dovecot and dovecot-pigeonhole back to 
> 2.2.10-8.el7.x86_64
> Regards
> Gonzalo 
> 

Re: index problems after update

[Gonzalo Palacios Goicolea via dovecot]

El 21/02/2019 a las 10:51, Aki Tuomi via dovecot escribió:

On 21.2.2019 10.53, Hajo Locke via dovecot wrote:

Hello,

Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot:

On 18 February 2019 09:28 Hajo Locke via dovecot
 wrote:


Hello,
     it seems we need a dovecot developers opinion. May be we hit a
bug or cant help ourselves.


Thanks for your answer.

Core dump with backtrace would help, if possible to acquire. Please
refer to https://dovecot.org/bugreport.html for information how to
get a core dump.

Aki


Unfortunately its hard to get a backtrace because dovecot is not
crashing. so it seems to be more a kind of logic problem in code and
no unexpected situation.
yesterday evening i had next incident. I upgraded from 2.2.33.2 to
2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken
index and delivers no new mails. it starts delivering if i delete
index files. At this point i cant tell if 2.2.36.1 also has same bug
and writes a damaged index, but very likely.  We dont know this
problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on
mbox-index code must happend which leads to this big problem. So imapd
cant do what he was created for.

For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and
will try this. In my opinion this is a major problem and i expect a
lot of affected people with version > 2.2.22 and classic mbox-storage.

Thanks,
Hajo

We consider mbox + procmail setup somewhat edge case, and if the core
dump does not point into something more generic, it will probably not
get fixed. It is more likely to have this working if you use
dovecot-lda/lmtp with sieve instead of procmail.

Aki


Hi Aki,
In support of Hajo I've to say that a few days ago I posted a similar 
issue, and I use dovecot-lda+sieve. My environment has RHEL6 and 7 
servers. When I last updated the servers RHEL6 servers mantained 
2.2.10-1_14.el6.x86_64 version, while RHEL7 updated dovecot from 
2.2.10-8.el7.x86_64 to 2.2.36-3.el7.x86_64. When the RHEL7 servers (used 
for sympa) processed a message for a user, its indexes were corrupted, 
and the user could't access his inbox through webmail, so I had to 
delete dovecot.* files from the user mail path to get it working again.
My solution was to downgrade dovecot and dovecot-pigeonhole back to 
2.2.10-8.el7.x86_64

Regards

*Gonzalo
*

Re: index problems after update

[Hajo Locke via dovecot]

Hello,

Am 21.02.2019 um 12:18 schrieb Sami Ketola via dovecot:



On 21 Feb 2019, at 12.23, Hajo Locke via dovecot  wrote:
I think mbox+procmail is a classic setup and wide used and good solution for 
many usecases. Same setup we use many years.
We run ~2 mio mailboxes. our automated systems depends on this setup. creating 
mailboxes, managing mailboxes, creating automated filterrules, backupsystem to 
tell something of them. we can not switch our whole mailsetup to work around 
this bug.
How to get a dump if dovecot not crashing but has wrong behaviour? I would like 
to help and provide useful info, but it depends on kind of problem.
I think if a classic setup is not working in dovecot any more, this is a 
serious problem.

In you first email to this thread it says:


Feb  8 08:45:37 hostname dovecot[14882]: imap(myuser): Fatal: master: 
service(imap): child 14135 killed with signal 6 (core dumped)
yes, but this is not 2.2.33.2 from Ubuntu 18.04, this happend after 
update to 2.2.36.1
I try to get a coredump from 2.2.36.1, but after my tests the basic 
behaviour is the same as in 2.2.33.2 -> no new mails and no errormessage.

so iam not sure if this is really same problem or different.
I was able now to catch a coredump of 2.2.36.1
I hope this is helpful and leads to the original problem. output of bt 
full is here: https://pastebin.com/awdpN4U3



So imap is crashing and even dumping a core.

Also I must disagree with your mbox+procmail statement. mbox has always been 
very unoptimised mailbox format and everyone should be emphasised not to use it.
Also that combination has always had problems with indexing and file locking. I 
would not use it on high volume mailservers. Or even medium volume mailservers.
Thats true, but worked for long years with dovecot.  mbox+procmail long 
time was only possibility to store mails and iam sure a lot of people 
use it. Was there an official statement that support for mbox+procmail 
was dropped?
Ubuntu 18.04 is fairly new OS and they offer still no 2.3 version (may 
be same bug), they offer 2.2.33.2 and i think this problem will reach 
users just with a delay.

Please help, current situation is very unsatisfying.



Sami



Thanks,
Hajo

Re: Weird things in the mail queue

[Aki Tuomi via dovecot]

On 21.2.2019 13.47, Lionel Elie Mamane via dovecot wrote:
> I noticed a mail stuck in my mail queue. dovecot-lda was returning
> error 64 Invalid parameter given. (EX_USAGE).
>
> Weird, weird, weird. After some sleuthing, I found the sender address
> was firstl...@domain.tld, with a UTF8-encoded Unicode U+FEFF ZERO
> WIDTH NO-BREAK SPACE character (AKA byte order mark) between "First"
> and "Last" :)
>
> Since that is passed as the -f parameter to dovecot-lda, it was giving
> the 64 error.

Your MTA should not be passing this along.

Aki

Weird things in the mail queue

[Lionel Elie Mamane via dovecot]

I noticed a mail stuck in my mail queue. dovecot-lda was returning
error 64 Invalid parameter given. (EX_USAGE).

Weird, weird, weird. After some sleuthing, I found the sender address
was firstl...@domain.tld, with a UTF8-encoded Unicode U+FEFF ZERO
WIDTH NO-BREAK SPACE character (AKA byte order mark) between "First"
and "Last" :)

Since that is passed as the -f parameter to dovecot-lda, it was giving
the 64 error.

Re: index problems after update

[Sami Ketola via dovecot]

> On 21 Feb 2019, at 12.23, Hajo Locke via dovecot  wrote:
> I think mbox+procmail is a classic setup and wide used and good solution for 
> many usecases. Same setup we use many years.
> We run ~2 mio mailboxes. our automated systems depends on this setup. 
> creating mailboxes, managing mailboxes, creating automated filterrules, 
> backupsystem to tell something of them. we can not switch our whole mailsetup 
> to work around this bug.
> How to get a dump if dovecot not crashing but has wrong behaviour? I would 
> like to help and provide useful info, but it depends on kind of problem.
> I think if a classic setup is not working in dovecot any more, this is a 
> serious problem.

In you first email to this thread it says:

> Feb  8 08:45:37 hostname dovecot[14882]: imap(myuser): Fatal: master: 
> service(imap): child 14135 killed with signal 6 (core dumped)

So imap is crashing and even dumping a core.

Also I must disagree with your mbox+procmail statement. mbox has always been 
very unoptimised mailbox format and everyone should be emphasised not to use it.
Also that combination has always had problems with indexing and file locking. I 
would not use it on high volume mailservers. Or even medium volume mailservers.

Sami

Re: index problems after update

[Hajo Locke via dovecot]

Hello,

Am 21.02.2019 um 10:51 schrieb Aki Tuomi via dovecot:

On 21.2.2019 10.53, Hajo Locke via dovecot wrote:

Hello,

Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot:

On 18 February 2019 09:28 Hajo Locke via dovecot
 wrote:


Hello,
     it seems we need a dovecot developers opinion. May be we hit a
bug or cant help ourselves.


Thanks for your answer.

Core dump with backtrace would help, if possible to acquire. Please
refer to https://dovecot.org/bugreport.html for information how to
get a core dump.

Aki


Unfortunately its hard to get a backtrace because dovecot is not
crashing. so it seems to be more a kind of logic problem in code and
no unexpected situation.
yesterday evening i had next incident. I upgraded from 2.2.33.2 to
2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken
index and delivers no new mails. it starts delivering if i delete
index files. At this point i cant tell if 2.2.36.1 also has same bug
and writes a damaged index, but very likely.  We dont know this
problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on
mbox-index code must happend which leads to this big problem. So imapd
cant do what he was created for.

For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and
will try this. In my opinion this is a major problem and i expect a
lot of affected people with version > 2.2.22 and classic mbox-storage.

Thanks,
Hajo

We consider mbox + procmail setup somewhat edge case, and if the core
dump does not point into something more generic, it will probably not
get fixed. It is more likely to have this working if you use
dovecot-lda/lmtp with sieve instead of procmail.

Aki


I think mbox+procmail is a classic setup and wide used and good solution 
for many usecases. Same setup we use many years.
We run ~2 mio mailboxes. our automated systems depends on this setup. 
creating mailboxes, managing mailboxes, creating automated filterrules, 
backupsystem to tell something of them. we can not switch our whole 
mailsetup to work around this bug.
How to get a dump if dovecot not crashing but has wrong behaviour? I 
would like to help and provide useful info, but it depends on kind of 
problem.
I think if a classic setup is not working in dovecot any more, this is a 
serious problem.


Thanks,
Hajo

Re: index problems after update

[Aki Tuomi via dovecot]

On 21.2.2019 10.53, Hajo Locke via dovecot wrote:
> Hello,
>
> Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot:
>>> On 18 February 2019 09:28 Hajo Locke via dovecot
>>>  wrote:
>>>
>>>
>>> Hello,
>>>     it seems we need a dovecot developers opinion. May be we hit a
>>> bug or cant help ourselves.
>>>    
> Thanks for your answer.
>> Core dump with backtrace would help, if possible to acquire. Please
>> refer to https://dovecot.org/bugreport.html for information how to
>> get a core dump.
>>
>> Aki
>>
> Unfortunately its hard to get a backtrace because dovecot is not
> crashing. so it seems to be more a kind of logic problem in code and
> no unexpected situation.
> yesterday evening i had next incident. I upgraded from 2.2.33.2 to
> 2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken
> index and delivers no new mails. it starts delivering if i delete
> index files. At this point i cant tell if 2.2.36.1 also has same bug
> and writes a damaged index, but very likely.  We dont know this
> problems with 2.2.22, between 2.2.22 and 2.2.33.2 a change on
> mbox-index code must happend which leads to this big problem. So imapd
> cant do what he was created for.
>
> For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and
> will try this. In my opinion this is a major problem and i expect a
> lot of affected people with version > 2.2.22 and classic mbox-storage.
>
> Thanks,
> Hajo

We consider mbox + procmail setup somewhat edge case, and if the core
dump does not point into something more generic, it will probably not
get fixed. It is more likely to have this working if you use
dovecot-lda/lmtp with sieve instead of procmail.

Aki

Re: index problems after update

[Hajo Locke via dovecot]

Hello,

Am 20.02.2019 um 10:39 schrieb Aki Tuomi via dovecot:

On 18 February 2019 09:28 Hajo Locke via dovecot  wrote:


Hello,
  
  it seems we need a dovecot developers opinion. May be we hit a bug or cant help ourselves.
  
  


Thanks for your answer.

Core dump with backtrace would help, if possible to acquire. Please refer to 
https://dovecot.org/bugreport.html for information how to get a core dump.

Aki

Unfortunately its hard to get a backtrace because dovecot is not 
crashing. so it seems to be more a kind of logic problem in code and no 
unexpected situation.
yesterday evening i had next incident. I upgraded from 2.2.33.2 to 
2.2.36.1, but same behaviour. Also 2.2.36.1 is tricked by the broken 
index and delivers no new mails. it starts delivering if i delete index 
files. At this point i cant tell if 2.2.36.1 also has same bug and 
writes a damaged index, but very likely.  We dont know this problems 
with 2.2.22, between 2.2.22 and 2.2.33.2 a change on mbox-index code 
must happend which leads to this big problem. So imapd cant do what he 
was created for.


For next incident i prepared a 2.3.2.1 on base of Ubuntu 18.10 and will 
try this. In my opinion this is a major problem and i expect a lot of 
affected people with version > 2.2.22 and classic mbox-storage.


Thanks,
Hajo