- dovecot - dovecot.org

[Dovecot] disabling SSLv2 in dovecot 1.2.17
by Steve Platt 09 Mar '12

09 Mar '12

I've set up a list of ciphers that excludes SSLv2 ciphers (and other weak ones) in the hope of preventing SSLv2 connections: ssl_cipher_list = TLSv1+HIGH : !SSLv2 : RC4+MEDIUM : !aNULL : !eNULL : !3DES : @STRENGTH However, this doesn't prevent the SSLv2 connection being allowed as our Nessus scans show and I'm tasked with trying to plug that "hole". I see Dovecot2 had the following change a year or so ago, in file src/login-common/ssl-proxy-openssl.c: - SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL); + SSL_CTX_set_options(ssl_ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2); I tried making the same change to dovecot1's src tree on our test system and it seems to have the desired effect; however I am very hesitant about putting this into our production system without seeking advice here first :-) Have I missed anything that's obviously bad about doing this please? Thanks again, Steve Platt

2 1

[Dovecot] [PATCH] Pop3 order in courier migration script
by Christoph Bußenius 08 Mar '12

08 Mar '12

Hi, I found a problem in the courier conversion script (courier-dovecot-migrate.pl). In some cases, it does not correctly preserve the order of POP3 UIDLs. Consider the following case, when courierpop3dsizelist contains: /2 9000 1327481629 AAA1:2,S 10000 21:1327481629 AAA2:2,S 10000 22:1327481629 AAA3:2,S 10000 23:1327481629 AAA4:2,S 10000 24:1327481629 AAA5:2,S 10000 25:1327481629 BBB11:2,S 10000 11:1327481629 BBB12:2,S 10000 12:1327481629 BBB13:2,S 10000 13:1327481629 BBB14:2,S 10000 14:1327481629 BBB15:2,S 10000 15:1327481629 and courierimapuiddb contains: 1 1327480919 9000 11 BBB11 12 BBB12 13 BBB13 14 BBB14 15 BBB15 16 CCC16 17 CCC17 18 CCC18 19 CCC19 20 CCC20 21 AAA1 22 AAA2 23 AAA3 24 AAA4 25 AAA5 then call courier-dovecot-migrate.pl --to-dovecot --convert and it will create dovecot-uidlist: 3 V1327480919 N9010 21 PUID21-1327481629 W10000 :AAA1:2,S 22 PUID22-1327481629 W10000 :AAA2:2,S 23 PUID23-1327481629 W10000 :AAA3:2,S 24 PUID24-1327481629 W10000 :AAA4:2,S 25 PUID25-1327481629 W10000 :AAA5:2,S 9000 :CCC17 9001 PUID12-1327481629 W10000 :BBB12:2,S 9002 :CCC16 9003 PUID15-1327481629 W10000 :BBB15:2,S 9004 :CCC20 9005 PUID14-1327481629 W10000 :BBB14:2,S 9006 PUID13-1327481629 W10000 :BBB13:2,S 9007 :CCC18 9008 PUID11-1327481629 W10000 :BBB11:2,S 9009 :CCC19 The problem here is that the BBB files are not in the same order as in courierpop3dsizelist, and will therefore have a different order in the UIDL response in POP3. Also, the CCC files are interleaved while they should appear at the end. The reason is how the script assigns new UIDs: It does not do this in the order of courierpop3dsizelist. In fact the order is random because it depends on how perl traverses hashes. The attached patch fixes this by sorting the messages: First the POP3 messages get their new UIDs in order of their appearance in courierpop3dsizelist (so that the UIDL order will really be the same as in Courier), after that, the IMAP-only messages will be checked for UID clashes. The patch also changes how the $prev_uid variable is handled because that was also needed to always get the order right. The algorithm could probably be optimized to reduce the number of UID re-assignments to a minimum, however this would complicate the code and would only be noticed in a few cases. The patched courier-dovecot-migrate.pl will create dovecot-uidlist like this: 3 V1327480919 N9010 21 PUID21-1327481629 W10000 :AAA1:2,S 22 PUID22-1327481629 W10000 :AAA2:2,S 23 PUID23-1327481629 W10000 :AAA3:2,S 24 PUID24-1327481629 W10000 :AAA4:2,S 25 PUID25-1327481629 W10000 :AAA5:2,S 9000 PUID11-1327481629 W10000 :BBB11:2,S 9001 PUID12-1327481629 W10000 :BBB12:2,S 9002 PUID13-1327481629 W10000 :BBB13:2,S 9003 PUID14-1327481629 W10000 :BBB14:2,S 9004 PUID15-1327481629 W10000 :BBB15:2,S 9005 :CCC16 9006 :CCC17 9007 :CCC18 9008 :CCC19 9009 :CCC20 Cheers, Christoph -- Christoph Bußenius Rechnerbetriebsgruppe der Fakultäten Informatik und Mathematik Technische Universität München +49 89-289-18519 <> Raum 00.05.055 <> Boltzmannstr. 3 <> Garching

2 3

[Dovecot] v2.1 latest hg: untagged reply to namespace command
by e-frog 08 Mar '12

08 Mar '12

Hello Timo, There seems to be something broken in v2.1 latest hg version: # 2.1.1 (94de7605f50f) 1 namespace * NAMESPACE (("" "/")("virtual/" "/")) NIL NIL * OK Namespace completed. Please note that the "OK Namespace completed." is send untagged. It worked on below version: # 2.1.1 (315f0d8cc2b2) 1 namespace * NAMESPACE (("" "/")("virtual/" "/")) NIL NIL 1 OK Namespace completed. Thanks, e-frog

1 1

[Dovecot] Shared mboxes
by Steve Campbell 08 Mar '12

08 Mar '12

I've been looking at some documentation on shared mail accounts. But I'm getting mixed thoughts on how this can or should be done. I use mbox for all my pop and imap folders since I've converted from a uw-imap server. The first thing that makes me wonder about setup is that I've been told to not use maildir and mbox on the same machine, although I'm not really sure why since it seems this would work OK, but anyway, I'm guessing I should stick with mbox for the shared accounts. Secondly, I'm sure I'd need a namespace to use which ever format, so there's private, public, and shared types. Most of the stuff I'm reading seems to suggest "public" as a type instead of "shared". So what's shared for anyway? I want to use this shared account so that email can be sent to this account, and be shared by only a few people, but I'm reading where locks and such don't work with mbox, so in my mind, how do you avoid corruption and why not just make a normal account and let people hack away at the data? I've not even got to the questions in my mind about how to set up the account, but figured if I could get the above straight, I might be able to fuddle my way through it. Help would be truly appreciated. steve campbell

2 6

Re: [Dovecot] dsync replication available for testing
by Michael Grimm 08 Mar '12

08 Mar '12

Hi -- On 08.03.2012 12:35, Timo Sirainen wrote: > On Thu, 2012-03-08 at 11:26 +0100, Michael Grimm wrote: > You can do for example: > > service config { > unix_listener config { > user = vmail > } > } I will try that later. >> It seems to me, that whenever a larger number of mails arrive on >> both >> servers simultaneously, the replicator gets into trouble [1]. I am >> unsure if one can expect that a replicator should deal with such >> stress, >> though. Or? > > Were these mails delivered via LMTP or dovecot-lda? LMTP > The locks should prevent duplicates I think, so there's something > still > going wrong. Just to be sure that I didn't misunderstand your proposed configuration: @mx1: plugin { mail_replica = remote:vmail@mx2.example.tld } @mx2: plugin { mail_replica = remote:vmail@mx1.example.tld } I do need to define one mail_replica plugin at each server pointing to the other one, correct? Regards, Michael

1 0

[Dovecot] duplicates with multiple To/CC and sieve redirect copy
by Adam Szpakowski 08 Mar '12

08 Mar '12

Hi, In one installation we are using sieve "redirect :copy" to create copy of the incoming email (local boss gets copy of its employees mails). There is a problem when the incoming email has multiple To/CC entries with local users. Multiple copy/redirects are created (one for each employee) and there are multiple copies in "boss" account. Each of this emails has the same Message-ID. Is there a way to detect those duplicates and discard them when saving copies into boss account? There was a discussion on the list a while ago (Feb 10/11, 2011) mentioning this problem, but with no clear solution. We are using Dovecot 2.0.15. Mail is delivered via LMTP (MDA/postfix is on separate machine then MAA/dovecot). -- Adam Szpakowski

5 10

[Dovecot] Failing: doveadm sync <--remote host--> dsync mirror
by Michael Grimm 08 Mar '12

08 Mar '12

Hi -- I'm used to dsync my two mailservers running 2.0.16. Today, I did upgrade one server to 2.1, and doveadm sync is throwing to following error: mail> doveadm sync -f -u test ssh vmail(a)remote-host.tld dsync -v -f -u test doveadm(test): Fatal: All your namespaces have a location setting. It should be empty (default mail_location) in the namespace to be converted. Same error with old running command: vmail> dsync -v -f -u test mirror ssh vmail(a)remote-host.tld dsync -v -f -u test doveadm(test): Fatal: All your namespaces have a location setting. It should be empty (default mail_location) in the namespace to be converted. Here's an excerpt of my doveconf -n: mail> doveconf -n mail_home = /var/mail/homedirs/%n mail_location = mdbox:/var/mail/maildirs/%n passdb { args = /usr/local/etc/dovecot/dovecot-sql.conf driver = sql } userdb { driver = prefetch } userdb { args = /usr/local/etc/dovecot/dovecot-sql.conf driver = sql } Reverted back for the time being (production servers) until I do understand the issue. Searching Google with "Fatal: All your namespaces have a location setting." only shows closed bugs back in 2010. Do I have to upgrade both servers to get syncing running? Any hint, help is highly appreciated. Thanks, Michael

2 18

[Dovecot] FW: Centos 6 + dovecot 2 + mail.app + imap
by Marc 08 Mar '12

08 Mar '12

Anybody also experiencing that imap processes are kept running/open by mac osx mail.app, so eventually users are getting to the mail_max_userip_connections limit? Outlook / other clients seem to run fine. Thanks, Marc

1 0

[Dovecot] http://xi.rename-it.nl down?
by Jim Knuth 07 Mar '12

07 Mar '12

Hello, you knows, that http://xi.rename-it.nl is down? -- Mit freundlichen Grüßen, with kind regards, Jim Knuth --------- Die Oper ist eine hübsche Unterhaltung, die noch besser wäre, wenn nicht dabei gesungen würde. (Claude Debussy)

2 2

[Dovecot] Log sync errors (again)
by Stephen Davies 07 Mar '12

07 Mar '12

As suggested earlier, I deleted all .imap directories and the log sync errors stopped - for a while. They have now returned. It seems to happen for every mailbox that gets accessed. Dovecot version 2.1.1 with pidgeonhole 3.0.0 on Mandriva Linux. Could this interfere with sieve filters? Several users have filters but none of them seem to do anything. Mar 7 09:25:51 server dovecot: imap(john): Error: Log synchronization error at seq=2,offset=38708 for /home/john/Mail/INBOX/.imap/Weather Summaries/dovecot.index: Extension header update points outside header size Mar 7 09:25:51 server dovecot: imap(john): Error: Log synchronization error at seq=2,offset=41576 for /home/john/Mail/INBOX/.imap/Zerna/dovecot.index: Extension header update points outside header size Cheers and thanks, Stephen -- ============================================================================= Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia. Fax : 08-8177 0133 Records & Collections Management. Mobile:040 304 0583

1 0