OK, I have some more sane thoughts after we discussed our local situation. See inline comments.
On Wed, Jun 13, 2007 at 10:51:02PM -0500, Steven F Siirila wrote:
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?
This is still an open question, but not as important to be answered now.
If not, are there any options I can provide to Dovecot LDA to make it function without index file updating?
To answer my own question, one could probably use a very large value for 'mbox_min_index_size'.
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).
For the mbox case (our immediate concern) your patch seems perfect, provided that it is performing the read of the access time and the re-setting of the access time during the time that the INBOX is locked. Timo, is this the case?
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?
What we are considering doing is updating our local "mailattrd" to lock using the same mechanism Dovecot is before reading the access time:
lock /var/mail/user (open RDONLY, fcntl SETLKW)
stat /var/mail/user (to get last access time)
unlock /var/mail/user (close)Unfortunately, it is more overhead. But it should be 100% accurate. This should give us an accurate "last time the user accessed their INBOX". I'm not sure how this would work with other mailbox formats, but we'll cross that bridge when we get there.
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