At 3:31 PM -0500 3/31/08, Chris Richards wrote:
Charles Marcus wrote:
On 3/31/2008, Chris Richards (gizmo@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:
- Is accessing a mailbox via POP3 and IMAP at the same time considered to be a Bad Thing?
No.
- Is having procmail drop messages directly into the directory that the IMAP process is scanning a Bad Thing?
No.
- 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@scconsult.com