search for: tkay

Hi, I am getting intermittent error messages in the log when my mail client tries to create/open a folder named ".imhoprefs". Some accounts seem to able to do it, but I have at least one that gives the log error: Feb 7 09:29:54 acad-cl1 dovecot: imap(tkay): close() failed with index file (in-memory index): Bad file descriptor I traced through the code, and it seems to be coming from mail_index_close() (line 1527 of mail-index.c), which seems to be attempting to close a file descriptor for an index. The funny thing is that since I am using in-memory...

Hi, I think I already know the answer to this and I agree with it, but I have a question about "invalid" mailbox naming decisions in dovecot. Technically, RFC3501 (Section 5.1, pg. 18, client consideration 3) says that * and % are legal in mailbox names, though it implicitly discourages their use. We just migrated to dovecot, and unfortunately have a few users who used * in their

The configuration files has settings that seem to address the issues of using indexes on NFS (i.e. locking and mmap fixes), but we are using Dovecot on NFS, and when the load gets high we start to see a lot of NFS stale file handle errors, particularly with MS clients like Outlook. I see the discussion about these errors from last year. Any updates on the state of the code? Should we be using

...o Trash: noop (completes OK, but does not see new messages) ...wait a few seconds... noop (connection drops...no response) Attempt to reconnect: mailbox locked. Will override in 270 seconds. The dovecot logs contain the following for the exact time when the connection drops: dovecot: IMAP(tkay): file mail-index-sync-update.c: line 686 (mail_index_sync_update_index): assertion failed: (view->hdr.messages_count == map->hdr.messages_count) I cannot correlate this to the user/folder, but this message is usually nearby: child 22915 (imap) killed with signal 6 -- Anthony Kay Univers...

Hi, I am using Dovecot 1.0 beta 7, moving to beta8 probably tomorrow. I am seeing a few RFC compliance issues with IMAP responses. I have an in-house IMAP client that caches IMAP data for a web mail system (it parses millions of IMAP interactions a day), and it reports whenever it gets a line that does not look RFC compliant. Unfortunately, users modify their mailboxes before I can get a copy

There was a patch posted to fix dotfile folder names in this mail: http://www.dovecot.org/list/dovecot/2005-July/008127.html I have a web mail client (which stores preferences in a dot-file/folder through IMAP) and pine users (address book is a dot-folder in IMAP) that this affects. I can certainly hand-apply the patch, but I'd feel a lot more comfortable if this had some future in the real

How does Dovecot handle accounts when writes are denied, such as in situations when a user is over quota, or the filesystem is full? -- Anthony Kay University Computing Center (541) 346-1719 GPG Fingerprint: B0DB D46A 60AF FAE7 A94A 5075 0CB4 4D88 9F4F 7F09 Only a statue can be perfect, and even then it casts a shadow. - Merle Fossum

Hi, We are using Dovecot with maildir, and the mail client requests flags, internaldate, and uid for all messages on folder open, which on average takes 3 seconds, but for large folders is much longer. It seems like I want mail_cache_fields to include "flags", but which date corresponds to internaldate? date.received? Is UID always cached for messages, or does it have to read through

If a mail folder contains quotes, the IMAP server may respond with a line like: 1 list "" "a/b/"X" Y Z" The specific example I saw had this exact form (it was in a nested folder, and one of the words was quoted). -- Anthony Kay University Computing Center (541) 346-1719 GPG Fingerprint: B0DB D46A 60AF FAE7 A94A 5075 0CB4 4D88 9F4F 7F09 Physics is like sex: sure,

I mis-read the line. -- Anthony Kay University Computing Center (541) 346-1719 GPG Fingerprint: B0DB D46A 60AF FAE7 A94A 5075 0CB4 4D88 9F4F 7F09 This isn't right. This isn't even wrong. Wolfgang Pauli

Hi, Mac mail (a horribly mis-behaved client, it seems), has a horribly hard time deleting/copying large blocks of messages from one folder to another. The basic symptom is: 1. Select a bunch of messages 2. Click on delete 3. Wait for a _very_ long time. It also seems very slow on copying, so it may be the "trash folder copy on delete" that is really slowing it down. Anybody else seen

In the midst of evaluating Dovecot for use in solving some mbox locking issues (while also waiting for our eventual migration to maildir), I had an epiphany. It looks like Dovecot's auto-detection of mail formats would allow us to migrate from mbox to maildir on a user-by-user basis! I was thinking: 1. Let dovecot autodetect mail storage 2. Use some procmail trickery to detect which format

Hi, We are thinking of converting to Dovecot to lighten our I/O load. I have done some performace tests comparing UW-IMAP to Dovecot when using mbox format if anyone is interested. They primarily examine the I/O improvements that can be gained from using Dovecot over UW when staying with mbox format: http://whizzo.uoregon.edu/public/src/mailperf/results.html I had too much cached for this set

Hi, We are using mbox and UW IMAP, and are having issues because UW IMAP does not support multiple client access when you use NFS for the mail files. I've done some research (see the comments after my 2 questions below), and most of the other major IMAP servers simply don't support it (courier is about the only one that has a positive comment). How much testing have you done