similar to: 0.99.10.7-rc1

Hello, I'm willing to swear that with the 0.99.10.4 Debian package in my rather extensive tests with mailbox format dovecot created not only any missing parental directories but also the INBOX file, but the later I can't prove/test now as I upgraded all respective boxes. However 0.99.10.5 will still create (if needed and possible) missing directories for mbox storage, just not an

Hello, running 0.99.10.6 (but seen it before that, too). Also (quite obviously) running 5 auth processes, given the fact that this is a pretty busy box and I didn't want to introduce any artificial bottlenecks. Alas with them eating up half of the free memory (which would go to a much better use as FS cache) I'm getting sorta concerned. If it's not a leak, it's caching something

Hello, The users here have been migrated to the new mail system with dovecot 0.99.10.5 (Debian package) on the backends. Storage is maildir, only pop3 access for now. I see very seldom occurrences (compared to the session wide pop lock of qpopper on the old system) like this: --- Jun 16 14:35:52 mb01 pop3(user at gol.com): Timeout while waiting for release of exclusive fcntl() lock for index

Hello, With qpopper you get something like this after a successful login: --- +OK test has 6 visible messages (0 hidden) in 11822 octets. --- This gives a clueful user or support people a quick status about the size of this mailbox, very helpful in full quota scenarios. Would be nice if the next dovecot would have such a feature as well. I doubt the same is (easily) applicable for IMAP (though

Hello, just to soothe my paranoia from many years of qpopper usage, which enforces solitary access to a POP mailbox. Only one login per user is possible at the same time and if a session terminates w/o qpopper being properly notified it will remain locked for some time, 30 minutes by default. With dovecot (0.99.10.4) one can login multiple times (using POP, with IMAP of course this comes as

Hello, I'm in the process of migrating 0.99 dovecot maildir boxes to a pair of new machine. These servers were running the stable (etch) 1.0rc15 package of dovecot until yesterday and existing .customflags files were correctly converted to dovecot-keywords. Yesterday I upgraded to the (finally, thanks to who did this) 1.0.0 etch backports package and since then freshly migrated boxes get

Hello, even though Timo seems to be hibernating (it's not _that_ cold in ole Suomi ;) I'd like to beg for a feature that would be very much appreciated over here. If something like this is already present and eluded my thorough archive and doc searches, feel free to smack me and then point me to the right direction. Feature request: More extensive session information and statistics in

> 1. 256GB of real RAM, swap is for chums. Are you sure that 100,000 IMAP sessions wouldn?t work well with SWAP, especially with fast SSD storage (which is a lot cheaper than RAM)? Seems that these IMAP processes are long lived processes (idling most of the time) that don?t need that much of the contents of real memory available for much of the life of the process. I use a database proxy in

> 1500 IMAP sessions will eat up about 3GB alone. Are you saying that Dovecot needs 2MB of physical memory per IMAP session? If I want to support a max 100,000 IMAP sessions per server, I should configure the server to have at least 200GBs of SWAP? > On Feb 10, 2017, at 3:58 AM, Christian Balzer <chibi at gol.com> wrote: > > On Fri, 10 Feb 2017 01:13:20 +0530 Rajesh M wrote:

Thanks for the info. I do have one further question for you. On your servers that are currently handling 50k IMAP sessions, how many users does that correspond to? Since many users will have multiple IMAP sessions on multiple devices, I?d like to hear about some real-world numbers that could be used for budgeting a new project like mine. Also, do you use Dovecot IMAP proxies in front of your

thanks for your help happy to say that the performance dramatically improved after i use the high performance settings from here http://wiki.dovecot.org/LoginProcess grep Login: /var/log/mail.log.1 |wc -l with the mail.log being of a typical, busy day. 412992 i also picked up the imap and pop3 connections during peak hours [root at ns1 domains]# doveadm who | awk

Hi, If I config my mta to write incoming mail to /var/mail/[username] and dovecot (or any other imap/pop server) is serving email from this file, can't the fie be corrupted while mta and dovecot read/write at the same time ? is there any mechanism to avoid it ? thanks --Y

Pretty simple bug, fixed finally. For 0.99.x: http://dovecot.org/patches/sql-ldap-auth-leak.diff Next 1.0-test release (or next nightly snapshot) fixes it for 1.0-tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL:

I upgraded Dovecot and it was smooth except some of my users using POP3 and leaving their mail on the server, are getting all their mail again. Is there a way to prevent this from happening in the future? /var/run/dovecot was kept during the upgrade ... Thanks, LDB

Hello, Dovecot 2.2.27 (Debian Jessie backports). When issuing a "doveadm kick" for a specific user I was greeted by: --- "warning: other connections would also be kicked from following users:" --- and a list of 22odd thousand users. As it turns out, kick wants to smack the hibernation proces(ses) that have hibernated sessions for this user, obviously the wrong approach here.

christian the servers i currently own are dell servers. The servers i plan to buy are Dell R530, 2U rack servers with 8 x 3.5 inch drives, with 64 gb ram each, Hardware raid. I am thinking of 2 X 300 gb ssds raid1 and 6 x 2 tb drives in raid10 for data. I do not have any experience in setting up drdb (that would be my next step) ... primarily using standalone servers with hardware level

Hi, I've very old Dovecot version so I'm trying to migrate new disk and current version of dovecot. But POP3 accounts have "version 1" .INBOX/dovecot-uidlist files so clients download the messages again. How can achieve not to download to mailbox after copy to new disk? Is there any script or something to migrate index v1 to v3? thanks for your suggestions.

Hello, as mentioned before, we are migrating our mailboxes from a 0.99 cluster to a 1.0.0 one. With 0.99 dovecot-auth (with LDAP as backend) was leaking quite happily and the dovecot-auth processes frequently did hit their size limit and thus were killed and restarted. Which in 0.99 at least lead to authentication failures on a busy server, as the dovecot master process just killed off the auth

http://dovecot.org/test/ Two important fixes: - Fixes the recently reported dovecot-auth crashes with unexpected client input - Fixes mbox corruption in some not-so-common cases. Hopefully this is the last one. I added more asserts anyway which try to catch similiar mistakes and avoid losing data. Others: - Added oe-ns-eoh workaround for pop3. Fixes outlook/netscape problems with buggy

In what must surely be the first sign of the apocalypse, Debian is actually freezing in preperation for a new release. Probably the last day for uploads will be August 17. Is there likely to be another dovecot release by then? In the event of 0.99.10.9 being the released version, are there any other patches Debian users would like me to include? -- Jaldhar H. Vyas <jaldhar at