On Thu, Jun 14, 2007 at 06:22:45AM +0300, Timo Sirainen wrote:
On Wed, 2007-06-13 at 17:52 -0500, Steven F Siirila wrote:
We are running Dovecot 1.0.0 using mbox format (currently in the midst of conversion from UW IMAP). We discovered today that the Dovecot LDA is accessing the user's INBOX at delivery time!
Well, there are two things:
- It always makes sure that the mbox file ends with "\n". I guess this isn't all that important, but I'm not really interested in just removing the code.
If that were the only reason for opening in read mode I'd lobby for this to be changed. :)
- If index files are fully synced, Dovecot writes X-UID: header. It also updates nextuid field in X-IMAP: / X-IMAPbase: header of the first message, which causes Dovecot to read() the file. The nextuid update isn't really required, but I think some other bug shows up if it isn't done.
Do these operations apply to Deliver or just IMAP/POP?
Not knowing enough about how the indexes work.... Question: Is it possible for Deliver to append a message w/o writing an X-UID header, leaving that operation to the IMAP/POP client code, and still maintain an updated index?
If not, are there any options I can provide to Dovecot LDA to make it function without index file updating?
It would be possible to check the atime before any reading is done and then later after message is saved it could be updated back. Hmm. Well, attached a patch that seems to work. I'm not sure if I want to add it to v1.0.1.
Hmm. I wonder how much of a timing window is left; this could be a viable option for us. However, I would like to consider our future options for mailbox formats other than mbox (we will eventually migrate I'm sure).
What we have is a daemon called "mailattrd" on our mail servers which runs on a TCP port and simply does a stat() on a user's mailbox and returns the atime, mtime, ctime values of said mailbox. That "service" is used by a variety of our applications. We were thinking of another possibility: changing Dovecot IMAP/POP to update the last access time (open in READ) of a specific file other than the user's INBOX. However, we'd rather not maintain local modifications unless absolutely necessary. Any thoughts on alternatives which might be mailbox-format-independent?
Thanks Timo for your super and timely support -- it is greatly appreciated!!
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593