similar to: Procmail and dovecot interactions

Hello, I am running dovecot-1.0-0_34 on Centos 4.4 In dovecot.conf I have: default_mail_env = maildir:/var/spool/mail/vhosts/%n/%d the content of that folder is: drwxrwxr-x 3 vmail vmail 4096 Dec 30 05:23 .. drwx------ 5 vmail vmail 4096 Sep 12 13:55 .Drafts drwx------ 5 vmail vmail 4096 Dec 29 18:26 .Sent drwx------ 5 vmail vmail 4096 Dec 30 03:37 .Trash drwx------ 5 vmail

I'm seeing two bogus messages appearing my Maildir/cur directory. They're dovecot.index.log and dovecot-uidlist. -rw------- 1 gsexton users 51 Feb 4 09:04 Maildir/cur/dovecot-uidlist:2,S -rw------- 1 gsexton users 244 Feb 4 09:04 Maildir/cur/dovecot.index.log These files are only appearing in the Maildir/cur directory, and not in any other directory that mail is delivered to (e.g.

On 2/5/2015 12:56 AM, Steffen Kaiser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 4 Feb 2015, George Sexton wrote: > >> I'm seeing two bogus messages appearing my Maildir/cur directory. >> They're dovecot.index.log and dovecot-uidlist. >> >> -rw------- 1 gsexton users 51 Feb 4 09:04 >> Maildir/cur/dovecot-uidlist:2,S

>From http://www.dovecot.org/list/dovecot/2008-June/031235.html: > > I have noticed that the entries in the dovecot-uidlist files don't seem > > to get updated when an email is deleted or moved to .Trash. It appears > > that this list list would just keep growing over time, being full of no > > longer used filenames, and must tend to increase its processing >

Hello, I've ran into problem with Dovecot and dsync replication. Everything works perfectly, including replication of sieve scripts, except fact that if user activates the 'managesieve' ruleset (I'm using currently Roundcubemail) on "mail1" host, it wouldn't be activated on "mail2" host, by creating symlink ".dovecot.sieve ->

Hello, I would like to know what is the proper way to restore a Maildir : Assuming someone has got a foobar/[cur|new|tmp] maildir, loses for some reason its content and that some new mail (seen and/or unseen) comes into that mailbox inbetween (that is before the restore procedure takes place, thus creating the need to merge restored messages and new ones). I'd like to check the following (I

Hello: We have a Fedora Core 2 (FC2) server with Dovecot and Procmail. Versions are: dovecot-0.99.13-4.FC2 procmail-3.22-13 We use "maildir" below home directory like: /users/operaciones/epezoa/maildir, where "epezoa" is my account. If I receive an e-mail, is stored at "new" folder. When I try to get e-mail from server, message is transfered from

I recently moved from Fedora 13 to Fedora 14 and consequently to dovecot 2.0.8. Since then, I have observed that messages are not being marked as read in all cases. The general behavior is: 1. Use my mail client to read all unseen messages. All mail folders show no messages unread. 2. Tell mail client to check for new mail. 3. Mail client now says that some folders have new mail (1 or more

Hi, Currently using dovecot 2.3.2.1 and pigeonhole 0.5.2 on two identical hosts. I recently noticed ".dovecot.sieve" and ".sieve/managesieve.sieve" are not replicating from one host to the other in either direction. Mail is having no trouble replicating on both hosts with dsync, it is only sieve files that are not replicating for unclear reasons. # doveconf -n host 1:

I'm using procmail as the local delivery agent for Maildir style mailboxes. I discovered that I was able to send mail to other users but was unable to send mail to myself. Examples from verbose procmail log: **** Successful message to another user **** procmail: [24589] Fri Jun 2 15:03:34 2006 procmail: Assigning

I'm using RC15 on Solaris 9. The wiki indicates that when a dovecot-shared file exists, "Dovecot uses the same permissions and GID when it creates index files, dovecot-uidlist file, new mail files, etc." In my case, Dovecot *is* creating new index files based on dovecot-shared, but dovecot-uidlist and individual message files don't completely match the permissions/group

Hi, We set up a new mail server and moved users' "cur,new and tmp" folders only into new mail server from old server.In other words we did not copy and paste dovecot.index,dovecot-uidlist,etc into new server from old server because they were created automatically.After bringing the new server up,users(microsoft office outlook) complained their imap folders are missing.I investigated

I've just updated from 1.0.14 to 1.1.1 (Maildirs). According to <URL:http://wiki.dovecot.org/Upgrading/1.1>, "dovecot-uidlist file is in a new format. The old format is automatically converted to new one." When I try to delete a message (which moves it to the IMAP Trash folder), I get the following looping sequence of errors until I cancel the delete operation in the mail

Hi Everybody, I'd like to start archiving e-mails by moving them to a server with running Dovecot. I installed "dovecot-core" and "dovecot-imapd" (version 2.3.4.1) on Debian 10. One of a few configurations I made is to use Maildir: # grep '^mail_location = ' /etc/dovecot/conf.d/10-mail.conf mail_location = maildir:~/Maildir I successfully moved some e-mails (at

I need for my dovecot-uidlist to be updated with next id when new email arrives (moved from new/ to cur/). This only happens now when I check for new email with my client. Setting maildir_empty_new = yes is not working. Do I have to uncomment something else as well maybe? I want to do some proemial pipe lets say for 10 emails. All of them will have same UID since dovecot-uidlist is not updated.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 4 Feb 2015, George Sexton wrote: > I'm seeing two bogus messages appearing my Maildir/cur directory. They're > dovecot.index.log and dovecot-uidlist. > > -rw------- 1 gsexton users 51 Feb 4 09:04 Maildir/cur/dovecot-uidlist:2,S > -rw------- 1 gsexton users 244 Feb 4 09:04 Maildir/cur/dovecot.index.log > These

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 5 Feb 2015, George Sexton wrote: > On 2/5/2015 12:56 AM, Steffen Kaiser wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Wed, 4 Feb 2015, George Sexton wrote: >> >>> I'm seeing two bogus messages appearing my Maildir/cur directory. They're >>> dovecot.index.log

Hi, I'm using dovecot 1.0_beta3 on Gentoo Linux, and am experiencing a problem of what I call 'phantom mail'. This problem I have for a long time (pre 1.0), but at the moment I'm using 1.0_beta3 and the problem still is in there. My setup is as follows: - regular x86 box - running Exim and Dovecot - Exim saves new mail in maildir format in a local filesystem /mail/user/blabla

i'm tired of dealing with buggy clients so i'm moving more processing into the server-side. i configured procmail as LDA with maildir-style mailboxes. i would like to simulate an automatic "mark as read" feature during procmail processing. simplest way looks to be forcing delivery directly to Maildir/cur instead of Maildir/new, but i suspect this may screw up dovecot. will

Hello, Dovecot documentation states that the "random redirects to multiple servers" NFS solution is to be avoided and I'm investigation the actual risks of it and a way to put it to test. I'm running dovecot-1.2.6 with Maildir (indexes, mailboxes and control files are all on NFS) and I'm using procmail instead of deliver as the LDA. 1. Documentation says : "Dovecot