- dovecot - dovecot.org

[Dovecot] After Upgrade to Dovecot 2.0.5 SSL problems
by derunfehlbare＠freenet.de 18 Oct '10

18 Oct '10

Hi, I've upgraded my Dovecot from 1.2 to 2.0.5. Everything is working fine on my Gentoo, also login with imaps and pop3s. But: I have in my config autocreate folders for new users. After creating a new user (with PostfixAdmin) I see in my logfile with SSL enabled this: imap-login: Warning: SSL alert: where=0x4004, ret=560: fatal unknown CA [127.0.0.1] With SSL-disable, autocreation folders for new users is no problem. I've searched a fiew days for a solution, but I did not find anything. Also dovecot-page what describes running SSL does not help me. Here are the relevant config-sniplets: plugin { autocreate = Trash autocreate2 = Sent autocreate3 = Junk autocreate4 = Drafts autosubscribe = Trash autosubscribe2 = Sent autosubscribe3 = Junk autosubscribe4 = Drafts } service imap-login { inet_listener imap { address = * port = 143 } inet_listener imaps { address = * port = 993 } } ssl = yes ssl = yes ssl_cert =

2 1

[Dovecot] Backup recovery with mdbox
by Andre Nathan 18 Oct '10

18 Oct '10

Hello I'm using mdbox for mail storage. I'd like to give users an option to recover backups into a new folder, say, Backup-$date. Is there a simple way to do this? I was looking at tools like dsync and doveadm-altmove but apparently they're not intended for this kind of stuff. Thanks in advance, Andre

2 7

Re: [Dovecot] dovecot genesis v2.0.X
by Dennis Clarke 18 Oct '10

18 Oct '10

> On Mon, 2010-10-18 at 09:47 -0700, Jim Pazarena wrote: > >> So, my question is, respectfully, is dovecot V2.0.5 stable enough >> for prime-time on a busy ISP mail server? I'll install it myself >> independent of the FreeBSD ports tree if so. > > It's getting better :) I'll make 2.0.6 release this week again with more > fixes, but I still have a few bug reports that I haven't managed to > reproduce. I'm concerned with the very same question. I currently have 1.2.12 running very well and I see risk in an upgrade to ver 2.x. Unless of course the benefits outweigh the risks. I have been carefully watching the ver 2.x tree rev from week to week and I await the defacto signal from people that it is in fact at least as solid at 1.2.12, that signal being adoption by people in busy mail servers. So therefore I await ver 2.0.6 with a mix of conflicting anticipation and trepidation. :-) -- Dennis Clarke dclarke(a)opensolaris.ca <- Email related to the open source Solaris dclarke(a)blastwave.org <- Email related to open source for Solaris

3 2

Re: [Dovecot] dovecot genesis v2.0.X
by Dennis Clarke 18 Oct '10

18 Oct '10

> On Mon, 2010-10-18 at 13:46 -0400, Dennis Clarke wrote: > >> > I am running 2.0.5 (svn repository) in production for about a >> > thousand users without major issues. >> >> Please Sir, on what OS and architecture ? > > I think the stability has less to do with that, and more to do with what > parts of Dovecot you want to use. If your test setup works fine with the > most common clients you use, and it survives a bit of stress testing, it > should work fine. > > The things I still mostly worry about are some rare errors/crashes. There is still a rather large number of Solaris 8 Sparc servers out there running in production and based on the conversations I have had with some sysadmins they will upgrade them when the smoke comes out. That could be another five years. So, before you say "stability has less to do with that" you should see the horrendous work it takes to port an app from the open source world ( usually Linux people with tons of Linux-isms/GCC-isms in it ) over to an old POSIX/XPG4 ( POSIX.1-1990, POSIX.2-1992, POSIX.1b-1993, POSIX.1c-1996 etc ) compliant UNIX. My coffee cup needs whiskey some days ;-) -- Dennis Clarke dclarke(a)opensolaris.ca <- Email related to the open source Solaris dclarke(a)blastwave.org <- Email related to open source for Solaris

1 0

Re: [Dovecot] dovecot genesis v2.0.X
by Dennis Clarke 18 Oct '10

18 Oct '10

> > > I am running 2.0.5 (svn repository) in production for about a > thousand users without major issues. Please Sir, on what OS and architecture ? -- Dennis

2 1

[Dovecot] Split plugin config in diferents files
by Antonio Perez-Aranda 18 Oct '10

18 Oct '10

Hi all, Is possible to split dovecot.conf with a very very big plugin {} section? Maybe, some like apache with sites-enabled.d Then, we could have a file per plugin.

2 4

[Dovecot] Filtering IP address connections ?
by Frank Bonnet 18 Oct '10

18 Oct '10

Hello Is it possible to refuse connections from some IP address in Dovecot configuration ? Thanks

5 7

[Dovecot] Version checks and API/ABI/sonames
by Axel Thimm 18 Oct '10

18 Oct '10

Hi, pigeonhole/sieve check against dovecot's version comparing to what they have been built against. This means that whenever there is a minor version of dovecot released pigeonhole/sieve need to be rebuilt and then redistributed to users even if there is no need for it (I'm thinking of packaged versions of dovecot and dovecot-pigeonhole). Could the checks become ABI-version aware, so that rebuilds and redistribution are kept to a minimum? Maybe Timo is already keeping API/ABI stability between minor updates, so the version checks should be against the first two version components only. Thanks! -- http://thimm.gr/ - http://ATrpms.net/

2 1

[Dovecot] Retrieving unread message count
by Brandon Davidson 18 Oct '10

18 Oct '10

Timo, I'm working with a webmail client that periodically polls unread message counts for a list of folders. It currently does this by doing a LIST or LSUB and then iterating across all of the folders, running a SEARCH ALL UNSEEN, and counting the resulting UID list. Eventually I'd like to see it using RFC5819 LIST-EXTENDED, but that requires a fair bit of work. In the mean time I'm trying to speed up the existing iteration. I've got it working using 'STATUS "mailbox" (UNSEEN)', but the language in RFC3501 suggest that this may be slow. There is a counterproposal to use RFC4731 ESEARCH and do 'SELECT "MAILBOX"'; 'SEARCH RETURN (COUNT) UNSEEN'. >From an IMAP server perspective, which do you anticipate would be faster? >From a client perspective it seems like STATUS would be better since it involves less round-trips to the server and less output parsing, but given the warnings in the RFCs there is concern that it is in fact be more expensive. -Brad

2 5

Re: [Dovecot] Limit access to dovecot by domains?
by Alan Brown 18 Oct '10

18 Oct '10

> Date: Fri, 15 Oct 2010 15:09:57 +1100 > From: Jobst Schmalenbach <jobst(a)barrett.com.au> > Subject: Re: [Dovecot] Limit access to dovecot by domains? > To: Timo Sirainen <tss(a)iki.fi> > Cc: dovecot(a)dovecot.org > Message-ID: <20101015040957.GA3232(a)senna.barrett.com.au> > Content-Type: text/plain; charset=us-ascii > > On Thu, Oct 14, 2010 at 03:31:23PM +0100, Timo Sirainen (tss(a)iki.fi) wrote: > > > On Wed, 2010-10-13 at 18:08 +1100, Jobst Schmalenbach wrote: > > > > >> > > Maybe I could include a script that would check the reverse DNS record > >> > > of a connected IP and then I could filter????? > > > > > > Wonder if tcpwrappers would work? You could use that with Dovecot v2.0. > > I have read a few things about this, it looks like its not so good to do it this way, > besides having proper written daemons running from (x)inted is a system overhead. Huh? What are you talking about? If dovecot has tcpwrapper support and is compiled -DTCPWRAP then it can run as a standalone daemon and will consult the hosts.allow/deny files, no need for inetd of any type. man 3 hosts_access man 5 hosts_access for details on tuning. Tcpwrapper tuning is far more powerful than people realise.

1 0