[Dovecot] DoveCot IMAP and "inconsistent state" messages
dovecot-20061108 at billmail.scconsult.com
Tue Apr 1 05:14:00 EEST 2008
At 3:31 PM -0500 3/31/08, Chris Richards wrote:
>Charles Marcus wrote:
>>On 3/31/2008, Chris Richards (gizmo at giz-works.com) wrote:
>>>Dovecot is version 1.0.rc15
>>Upgrade please - rc15 is very old...
>Err, that's the newest thing in the yum repository, and if I go
>compiling code that isn't 'official' (i.e. doesn't come from the yum
>repository), I'll get myself in an awful lot of trouble. Management
>seems to be under the strange belief that only code from the
>repository it is 'safe'.
>So, the question is, how hard do I need to fight in order to get this done?
That's a question about the competence of the people maintaining that
repository. Presumably these would be the people who blessed a
pre-release version of Dovecot almost 18 months ago, in a period when
such versions were being released every few days *due to bugs*, and
who have not updated their build at any time since. It seems to me
that these are not people who should be tasked or trusted with being
the gatekeepers of software deployment, as that seems to be
demonstrably beyond their competence.
I don't say that as a slur on the people running the CentOS project,
but rather to note that the packaging service they offer is unsuited
to the role your management has given it in your company's
More to the point:
At 3:10 PM -0500 3/31/08, Chris Richards wrote:
>So, now I've got two questions:
> 1. Is accessing a mailbox via POP3 and IMAP at the same time
> considered to be a Bad Thing?
> 2. Is having procmail drop messages directly into the directory that
> the IMAP process is scanning a Bad Thing?
> 3. Is there a better/preferred way to have Postfix/procmail deliver
> mail to the maildir that will keep Dovecot IMAP happy? (There
> don't seem to be any issues with pure POP3 access).
Buffer overflow... was only expecting 2 questions. :)
But again, the answer is: No.
Note the nature of the problem: a new message has been assigned a UID
that isn't higher than all other existing UID's in that mailbox.
That is a violation of the IMAP spec (RFC3501 sec. 22.214.171.124) and
Dovecot did it. Nothing else sets UID's for messages. Once Dovecot
has noticed that it has made that mistake, it really needs to kick
out any IMAP sessions with that mailbox selected, because they are
fairly likely to have some impression that the
<mailbox><UIDVALIDITY><UID> triple including that new UID refers to a
particular old and probably expunged message and may end up trying to
work with it as if the new message is the old one. Dovecot will
provide a new UIDVALIDITY value to any later sessions selecting that
mailbox to prevent that sort of mistake, and any clients seeing that
will have to resynch their mappings of messages to UID triple.
The only solution to Dovecot making that sort of error is for Dovecot
to be fixed. The release announcements for later 1.0rc* versions seem
to describe such fixes.
bill at scconsult.com
More information about the dovecot