Re: Dovecot and imapproxy
> On September 20, 2016 at 12:45 AM Grantwrote: > > > imapproxy sped things up a lot for me when I was using courier. I > switched to dovecot a while back and kept using imapproxy. Lately > I've been noticing weird TCP Queuing spikes in my munin graphs and > discontinuing my use of imapproxy seems to have smoothed them out > completely and I haven't noticed a slowdown in webmail. Is imapproxy > generally not necessary with dovecot? > > - Grant It's not needed indeed. Aki
Dovecot and imapproxy
imapproxy sped things up a lot for me when I was using courier. I switched to dovecot a while back and kept using imapproxy. Lately I've been noticing weird TCP Queuing spikes in my munin graphs and discontinuing my use of imapproxy seems to have smoothed them out completely and I haven't noticed a slowdown in webmail. Is imapproxy generally not necessary with dovecot? - Grant
Re: Dovecot 2.2.25 fails on SSL
"Andreas M. Kirchwitz"writes: OK, the origin of your problem becomes clearer. You can hardcode these paths into the executables by doing something like env CFLAGS='-I/my'ssl/include' \ LDFLAGS='-L/your/ssl/lib -Wl,-rpath,/my/ssl/lib' \ configure ... Based on your mail I've tried CFLAGS/LDFLAGS again, and now Dovecot didn't even compile any longer. I don't use the same OS as you, but what errors dis you get? Joseph Tam
Re: Panic: file auth-request.c
> On September 19, 2016 at 8:23 PM Chris Wikwrote: > > > From: Tanstaafl > > To: > Sent: 19/09/2016 5:44 PM > Subject: Re: Panic: file auth-request.c > > On 9/17/2016 2:15 PM, Chris Wik wrote: > > So we upgraded to a new CentOS 7 server with SSD RAID, fast CPUs and > > tons of RAM. No more load problems. We compiled the latest dovecot > > from source (as the version from CentOS yum repo is already quite > > old, figure we might as well run the latest version since we were > > upgrading anyway). > > Then on 9/18/2016 6:50 AM, Chris Wik wrote: > > In my local source of 2.2.5, > > ??? > > Latest dovecot version is 2.2.25 - or was that (hopefully) a typo? > > http://www.dovecot.org/download.html > > > Yes, typo, sorry. > > > I have 2.2.25 sources and the line numbers don't match the diff. > > > We'll wait for 2.2.26, unless someone from Dovecot would like us to test the > patch? In which case I'll try removing the 2 lines and recompiling and see if > it works. > > > Chris It should work, it's been tried out. Aki
Re: Panic: file auth-request.c
From: TanstaaflTo: Sent: 19/09/2016 5:44 PM Subject: Re: Panic: file auth-request.c On 9/17/2016 2:15 PM, Chris Wik wrote: > So we upgraded to a new CentOS 7 server with SSD RAID, fast CPUs and > tons of RAM. No more load problems. We compiled the latest dovecot > from source (as the version from CentOS yum repo is already quite > old, figure we might as well run the latest version since we were > upgrading anyway). Then on 9/18/2016 6:50 AM, Chris Wik wrote: > In my local source of 2.2.5, ??? Latest dovecot version is 2.2.25 - or was that (hopefully) a typo? http://www.dovecot.org/download.html Yes, typo, sorry. I have 2.2.25 sources and the line numbers don't match the diff. We'll wait for 2.2.26, unless someone from Dovecot would like us to test the patch? In which case I'll try removing the 2 lines and recompiling and see if it works. Chris
Re: dovecot --hostdomain
Am 15. September 2016 16:10:02 MESZ, schrieb dove...@nspace.de: >Hi, > >I'm currently debugging replication issues and I found that both >servers >answer to a "dovecot --hostdomain" simply with > >localhost > > From what I've read, this can lead to problems. >Where do I configure the dovecot hostdomain name? The machine itself >has >a valid name in /etc/hostname Whats the output of the command `hostname`? Whats in your /etc/hosts? >Thanks, >Thomas
Re: Panic: file auth-request.c
On 9/17/2016 2:15 PM, Chris Wikwrote: > So we upgraded to a new CentOS 7 server with SSD RAID, fast CPUs and > tons of RAM. No more load problems. We compiled the latest dovecot > from source (as the version from CentOS yum repo is already quite > old, figure we might as well run the latest version since we were > upgrading anyway). Then on 9/18/2016 6:50 AM, Chris Wik wrote: > In my local source of 2.2.5, ??? Latest dovecot version is 2.2.25 - or was that (hopefully) a typo? http://www.dovecot.org/download.html
Logging of custom mail headers
Hi, I need to configure Dovecot to log some custom mail headers. I red the documentation of the mail_log plugin but I didn't found which field I've to use as value for mail_log_fields parameter. So, I red the plugin code but in mail-log-plugin.c there're defined only "from" and "subject" fields that match some email header. I found three alternatives: 1. use the mail_filter plugin (spawning a new process, ecc.) 2. coding a new plugin using the notify plugin 3. propose a patch to the mail_log plugin that use a new configuration parameter (es. mail_log_headers) and log the specified mail headers Which is the better solution for you? Thanks in advance Francesco
Re: Supporting RFC 5466 (IMAP4 Extension for Named Searches (Filters))
On 10/1/2014 3:21 PM, Stephan Boschwrote: > On 10/1/2014 2:42 PM, Jesus Cea wrote: >> I wonder if Dovecot supports RFC 5466 (IMAP4 Extension for Named >> Searches (Filters)) or if there is any plan about it. > I have a partial implementation in my patch queue. I haven't worked on > it for a few months now due to other projects that took precedence. It > still may take quite a while until I can continue that effort. I don't know if it is a good idea to resurrect such an old thread, but... Any chance there has been movement on this? There is a Thunderbird bug opened for supporting this: https://bugzilla.mozilla.org/show_bug.cgi?id=439047 and it would be much easier to try to push it forward if there was actually a server that supported it already. Thanks
Re: [Dovecot] Plugins: virtuals vs acls
On Fri, Sep 16, 2011 at 03:03:47PM +0300, Timo Sirainen wrote: ..On Fri, 2011-09-16 at 14:48 +0300, Leho Kraav wrote: .. ..> dovecot-virtual: ..> * ..>all ..> ..> when dovecot-acl files restrict some subset of * for a user, does ..> dovecot respect these ACLs when collecting messages for virtual folder? .. ..If they aren't respected, it's a bug. (dovecot-2.2.19) So, 5 years later, I got to implementing `dovecot-virtual` :) I'd like to set up a `LargeMailbox/Virtual/30d` mailbox that restricts the view of a hidden, and otherwise inaccessible `LargeMailbox` to "last 30 days" rolling window. `dovecot-virtual` for that is simple enough, but ACL-s get in the way. LargeMailbox ACL user=Moi none LargeMailbox/Virtual/30d ACL user=Moi lrwsip It looks like `docevot` is correctly restricting reading `LargeMailbox` - user Moi is able to subscribe the mailbox, but sees zero messages in there. How can I make `LargeMailbox` readable from a virtual without giving the mail client the ability to read all of `LargeMailbox` on its own? -- Leho Kraav, senior technology & marketing architect Mobile: +372-56-603673 G+: lkoogliz...@gmail.com
Re: Dovecot 2.2.25 fails on SSL
Joseph Tamwrote: >> For every program I compile myself, I link it against my custom >> OpenSSL library (always newest version; distributions usually tend >> to stick with a specific version and only apply security fixes). > > OK, the origin of your problem becomes clearer. You can hardcode these > paths into the executables by doing something like > > env CFLAGS='-I/my'ssl/include' \ > LDFLAGS='-L/your/ssl/lib -Wl,-rpath,/my/ssl/lib' \ > configure ... Yes, exactly, that's my usual approach. I've used this as well for building other software with custom libraries. Unfortunately, I remember CFLAGS/LDFLAGS didn't play well with Dovecot, so I used SSL_CFLAGS/SSL_LIBS as suggested by the documentation and that worked well. > I use this myself (except the -Wl part since these libs are > symlinked to my shared library path). I think "-R/my/ssl/lib" > might also be synonymous with -Wl,... Based on your mail I've tried CFLAGS/LDFLAGS again, and now Dovecot didn't even compile any longer. I was close to giving up. But obviously, I didn't ... :-) After some investigation I found the non-default linker option "-Wl,--as-needed" as problem which is enabled by Dovecot for unknown reasons. Finally, this call to "configure" generates proper Makefile files to build Dovecot with a custom SSL library: env CPPFLAGS="-I/usr/local/ssl/include" LDFLAGS="-L/usr/local/ssl/lib -Wl,-R/usr/local/ssl/lib" LIBS="-Wl,--no-as-needed -lcrypto -lssl" SSL_CFLAGS="-I/usr/local/ssl/include" SSL_LIBS="-L/usr/local/ssl/lib -Wl,-R/usr/local/ssl/lib -Wl,--no-as-needed -lcrypto -lssl" ./configure --prefix=/usr/local/dovecot --with-ssl=openssl (chances are that SSL_CFLAGS/SSL_LIBS could be removed completely but it won't hurt) I've read the section in the "ld" manual but still don't understand why Dovecot enables --as-needed (never seen that before with other software) and why it's such a big problem. But I'm no expert here. > I don't have that problem -- I use configure to tell dovecot where to find > my self-compiled openssl, and the resulting executables load from where I > want. Thanks for pointing me at the proper direction again. Now Dovecot 2.2.25 compiles for me with a custom SSL. I understand that this issue might not have a high priority but maybe one of the developers could check if "--as-needed" is really needed (as it confuses people who try to use custom libraries) and what's the deeper meaning of SSL_CFLAGS/SSL_LIBS. My system is a regular CentOS 6 (latest sub-release with all patches), nothing special except for a custom SSL installation. Greetings, Andreas