similar to: Hot to get rid of \"DON\'T DELETE THIS MESSAGE\" messages?

There are three applications that have their mitts on files on my mail server, which is running AIXV5.3 and UWIMAP and mbox format. The mail folders and INBOXES are native to that machine, but also are NFS exported to a login server and a mailing list server. All three machines are running the lockd daemon. Everybody wants to lock differently 1) procmail (delivering for sendmail), which

After experiencing these symptoms through many of the release candidates, we've been at v1.0.0 now for a few weeks, and they're still there. Perhaps a config issue with my setup (mbox locks?). It's really too disrupting to continue using this way. I've included symptoms, client info, mta info, log entries and config file. What other information can I provide? Please

I have Dovecot 1.0 in trial use by the IT staff, and have some locking questions Background, the mail server runs procmail, sendmail and NFS exports the user homedir and mailbox to a) a login shell host and b) a mailing list services host. It runs UWIMAP on the usual ports and dovecot on a arbitrary port number. Because of concern with NFS and file access contention. I have the following

I realized that my last message about locking gave bad information -- or rather, very little information. Here's my setup: - Home directories and user login information are located on an Xserve running Mac OS X 10.2.6. Home directories are split between 2 different directories -- /Users and /Students. Home dirs are exported via NFS to the mail server. User login info is shared via LDAP

Hello, I installed 1.2.3 and we are seeing a few messages in the log files such as: --- Aug 4 16:40:24 xyz dovecot: IMAP(john): fchown() failed with file /home/john/.imap/INBOX/dovecot.index.log.newlock: Operation not permitted Aug 4 16:40:24 xyz dovecot: IMAP(john): fchown() failed with file /home/john/.imap/INBOX/dovecot.index.tmp: Operation not permitted --- dovecot -n: # 1.2.3:

Hello, I''m trying to install the upload_progress gem and i can''t see the upload progress status. My config is : apache2 with mod_proxy mongrel rails upload.rb : ############## require ''rubygems'' require ''drb'' require ''gem_plugin'' GemPlugin::Manager.instance.load ''mongrel'' => GemPlugin::INCLUDE

With following configuration: userdb static { args = uid=10000 gid=10000 home=/home/vmail/domain.tld/%u/./ mail=maildir:~/maildirs } and accompanying passdb passwd-file consisting of only user and password, for example test:{PLAIN}test: dovecot will access home=/home/vmail/domain.tld/test/home/vmail/domain.tld/test/maildirs instead of home=/home/vmail/domain.tld/test/maildirs dovecot

Ok, I've ALMOST got this working ... I can run deliver as a user, but when I try using it as the default delivery agent from sendmail, I get deliver(userid): net_connect(/var/run/dovecot/auth-master) failed: Permission denied Does deliver run as root, as the recipient's ID, sendmail's ID or sendmail's GID? (I'm running freebsd) Or am I totally clueless ?? Here is dovecot

Generally, orphan scan run in ocfs2_wq and is used to replay orphan dir. So for some low end iscsi device, the delete_inode may take a long time(In some devices, I have seen that delete 500 files will take about 15 secs). This will eventually cause umount to livelock(umount has to flush ocfs2_wq which will wait until orphan scan to finish). So this patch just try to finish the orphan scan

I just migrated from a FreeBSD/Sendmail/UW-IMAP setup to RHEL 3/Postfix/Dovecot (1.0a5 currently). Both systems used Procmail as the final delivery agent (into inboxes or . Since the changeover, things have *mostly* been going ok, but I've been having some problems that I think are locking-related. I'm getting reports from users about IMAP hangs (mostly from Thunderbird). Sometimes I see

While experimenting a bit, I found that for some reason, locking indexes with flock is problematic, but only if user is taken from passwd-file. The host system is openbsd 3.9, dovecot's configuration is added at the bottom. Authentication is from two places - first from mentioned passwd-file, then from passwd file using bsdauth (in this case, there're no problems with flock). So, if

Dovecot 1.0.3 Deliver is saying this on two specific emails. Other emails to these 2 users are going through fine. Looking at the mail headers the only thing questionable I see is: From: "AMS Publication Division"@ams.org Is this the problem? # 1.0.3: /usr/local/etc/dovecot.conf base_dir: /var/run/dovecot/ protocols: imap pop3 listen(default): *:143 listen(imap): *:143 listen(pop3):

Had a user who couldn't access his INBOX: > Mar 21 09:21:17 penguina dovecot: imap([USER]): Panic: file > mail-index-sync-ext.c: line 209 (sync_ext_reorder): assertion fai > led: (offset < (uint16_t)-1) > Mar 21 09:21:17 penguina dovecot: imap([USER]): Error: Raw backtrace: > /usr/lib/dovecot/libdovecot.so.0 [0x342683c660] -> /usr > /lib/dovecot/libdovecot.so.0

Hi folks, I'm using the latest Dovecot 1.16 with Postfix for my FreeBSD box. Since v1.1.4 (if i remember correctly), the following message is displayed whenever starting Dovecot. "Info: If you have trouble with authentication failures, enable auth_debug setting. See http://wiki.dovecot.org/WhyDoesItNotWork" Besides that, Dovecot works great but I wonder what this message is all

>> symptoms: >> 1. Coming back to the idle client, and clicking on a newly arrived >> message, often a long delay (seems like minutes, sometimes) will >> occur before the message loads from the server. >> 2. Sending messages, as often as not, the client will stall, >> sometimes indefinitely, on "copying message to sent folder". >> >

Hi all, After I posted yesterday, I'm still struggling with dovecot 1.0beta1 I installed it on openbsd with no problem. But I can't get it to authenticate plaintext on Unixware. I had to add two include files <sys/types.h> and <sys/mkdev.h> in compat.h because minor and major where undefined on unixware. I doubt that could fail... What's wrong with that conf: ##

http://dovecot.org/test/ If dovecot-auth was crashing with you, this release should fix it. I don't know when it did though, I just applied a patch from Andrey Panin with that description :) Fixed also another dovecot-auth crash with Solaris and maybe some other systems. Contains the first attempt of a Dovecot LDA. It's still in pretty ugly shape, but it should work, more or less. I

Hi, I'm trying to get dovecot set up better. I am using 1.0alpha3. It takes a long long time to move messages for some reason. It seems it may be a timeout thing, because neither the client or server is using any cpu time or disk i/o or network to speak of. (To move maybe 400 messages, it seems to take maybe half an hour, maybe longer.) With alpha 2 I was getting messages from

Dear All, I want that if someone delete the mail from SPAM folder mail must be deleted permanently instead of moving the same to Trash folder. Is it possible with the dovecot right now ? Please let me know the solution for the same. Thanks

I was going to test 1.1.16 so as to see how it handles global ACLs (in the hope to have a possible comparison with 1.2.0's odd behavior), when I encountered the problem described hereafter. Note that just disabling ACLs is sufficient to get back a fully functional imap binary. So, should there be some plans for a 1.1.17 version, perhaps could the info provided here prove somewhat