Bug 206376

Got similar results with another folder.  This has a large message at the top
with a number of attachments.  The end of the message looks like this:

------_=_NextPart_001_01C6D52E.38C067FD--

From ...

If that top message is deleted the start of the folder looks like this:

.38C067FD--

From ...

This is different from the other one.  Instead of deleting part of the
following From line it leaves part of the last line and the blank line
from the deleted message.

Deleting that message from the same folder on 32 bit RHEL produces no
corruption.

Found another troublesome folder.  This one does cause problems on 32 bit
but not in the same way.  On 64 bit any time the top message is deleted 
the folder becomes corrupted.  On 32 bit it's only every second deletion!

I think I've found a solution: remove the X-UID headers and the problem
disappears for all the problem folders I've identified so far.

Apologies for the frequent posts but I was desperate to get this problem resolved.

Anyway I think I've solved it (for us at least).  I discovered that the problem
only occurs if the index files are in an NFS mounted directory.  (The default
puts them in the user's home directories which are NFS mounted in our case).

Configuring an index directory local to the mail server seems to have solved it:

   default_mail_env = whatever:INDEX=/var/cache/dovecot/indexes/%u

Don't worry and thanks for the info. I don't think there will be anything like 
an easy fix, but the workaround looks fairly good to me.

1)there is mentioned attachment for testing this bug, where this can be found?

2)there is mentioned this bug is related to NFS mounts, I don't know if NFS was changed recently, but is it possible to reproduce this right now? With new mbox?

thanks

The problem we had was fixed when I moved the index files out of the user's NFS mounted home directories onto local storage on the mail server.  The relevant setting in dovecot.conf is:

default_mail_env = mbox:~/mail/:INBOX=/var/mail/%u:INDEX=/var/cache/dovecot/indexes/%u

You need to create the directory /var/cache/dovecot/indexes on the mail server:

  mkdir -p /var/cache/dovecot/indexes
  chmod 1777 /var/cache/dovecot/indexes

It's only the INDEX files that need to be on local storage.  NFS mounted mail folders (in ~/mail) haven't caused any problems.


--
Ian

ok, to be clear (correct me if I'm wrong):
- you use workaround for index files so you don't know if this problem still exists

- you don't have mbox used for reproducer anymore

(In reply to comment #9)

> - you use workaround for index files so you don't know if this problem still
> exists

correct.  Having the index files on local store is also more efficient so it makes sense to configure it that way.

> - you don't have mbox used for reproducer anymore  

It's almost 3 years since we resolved this problem so no I don't have the test mbox files.  All the problem mbox folders had been migrated from UW imap but that's based on very limited testing.

--
Ian

ok, I'll try to reproduce it myself. thanks for the info

since workaround is known, lowering severity to high

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

I'm sorry for not addressing the issue in RHEL-4. As dovecot
was not scheduled for update in RHEL-4.9, I'm closing that bugzilla WONTFIX. If
you are still experiencing the issue with RHEL-5 or RHEL-6, feel free to reopen it against RHEL-5 or RHEL-6 respectively.