[Dovecot] DoveCot IMAP and "inconsistent state" messages

[Bill Cole]

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 
environment.

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?

No.

>   2. Is having procmail drop messages directly into the directory that
>      the IMAP process is scanning a Bad Thing?

No.

>   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. 2.3.1.1) 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 Cole                                  
bill at scconsult.com