similar to: Cache fields

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

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

Environment: Dovecot 1.0beta8 Host: 64 bit Red Hat AS4 Linux (2.6.9-34.0.1) Disks: NFS netapp In the case below, the two connections were going through two separate servers sharing disks via an NFS NetApp. Here is the sequence of operations: 1. Open a connection to a folder (say mail/Trash) 2. Open a connection to another folder (say Inbox) 3. Move messages from Inbox to Trash using this

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

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

Hi, If an IMAP fetch is issued some "short" time after a message was delivered with dovecot deliver then dovecot reports wrong (zero) values for that new message. Afterward, it reports the information OK. This causes problems to our IMAP client. The problem is easily reproduced with a large message on a slow machine. I'm using dovecot 1.0.10 Here's a sample trace: 1 uid fetch

Dovecot will soon have a plugin which allows running a nightly cronjob to expunge mails from configured mailboxes which have been in there for a configurable amount of time. For example the configuration could be: plugin { # Trash 7d, Spam 30d expire = Trash 7 Spam 30 } It also supports using Dovecot's lib-dict to keep track of the mailboxes and their oldest mail's timestamp, so that

> bclark wrote: > > > The interesting thing is, once I have some mail on the dovecot, > the date > > displayed on Mozilla is correct, but the mail shown throught > outlook, > > shows todays date (thats for all mail). > > Each mail has (at least) two dates : the date it was sent (stored > in the > headers), and the date it arrived (in Maildir, the

We're trying some migration tests ... from CommuniGate to Dovecot. The migration program does an APPEND into the new mailbox: src>: a0 FETCH 2900 (FLAGS INTERNALDATE RFC822.PEEK) src<: * 2900 FETCH (FLAGS (\Seen) INTERNALDATE "29-Aug-2005 18:36:54 +0000" RFC822 {1194157} src<: ) dst>: bAPP APPEND "INBOX" (\Seen) "29-Aug-2005 18:36:54 +0000" {1194157}

Hi, Dovecotters. In the Maildir code, dovecot-0.99.10/src/lib-storage/index/maildir/maildir-copy.c, I see that hardlinks are used. It seems that (line 185) if MAILDIR_COPY_WITH_HARDLINKS is exported, then copying is attempted by using link. Having problems reading the source / flow of control, I resort to this list. When a file is linked, the mtime is naturally kept on the destination. This

Using the latest dovecot-stable (20050213) with pine, I get an empty "from" header in my e-mails. This doesn't happen with 1.0.59-test, nor did it happen with the first dovecot-stable (20050131). A partial connection log is below: 1.0-test59: IMAP DEBUG 15:23:32 2/13: 00000007 FETCH 1:41 (UID ENVELOPE BODY.PEEK[HEADER.FIELDS (Newsgroups Content-MD5 Content-Disposition

Timo Sirainen wrote: > On Fri, 2007-10-05 at 17:27 -0700, Jeff Grossman wrote: > >> Timo Sirainen wrote: >> >>> On Tue, 2007-10-02 at 18:12 -0700, Jeff Grossman wrote: >>> >>> >>>> So, what would >>>> have changed between version 1.0.5 and 1.1beta2 to somehow make the >>>> phone think all of the messages are older

>>>>> Aki Tuomi <aki.tuomi at dovecot.fi>: > On 09.09.2017 12:33, Steinar Bang wrote: >> When a message is copied to a folder on dovecot with mbox storage, is >> the mtime of the saved mbox file set to the time of the save? [snip!] > Internaldate is picked from the separating 'From' line in mbox file. > "From user at example.org Thu Oct 20