- dovecot - dovecot.org

OT: Central sieve management
by list＠airstreamcomm.net 29 May '15

29 May '15

A bit off topic, but I was wondering if anyone here has a solution for centrally managing sieve for multiple users from a custom web application? We would like to implement pigeonhole sieve on our dovecot cluster, however we need to be able to access user’s sieve configurations from a central location for troubleshooting and support purposes.

3 3

Enabling Master User for migration
by Charles Marcus 29 May '15

29 May '15

Hi all, Ok, just need a quick-n-dirty way to enable a master user for a migration... Reading the docs, I'm not sure what the bare minimum is I need to do this... At: http://wiki2.dovecot.org/Authentication/MasterUsers The Example config shows: auth_master_user_separator = * passdb { driver = passwd-file args = /etc/dovecot/passwd.masterusers master = yes pass = yes } passdb { driver = shadow } userdb { driver = passwd } But, if I'm using a non-real user (just need a master user that can log in as all other users for the migration), do I need all three of these? Or just the first two? Or, just the first one? I think I need the first two and not the last one, but am unsure. This is on a production system so don't want to break things, and I'm unfamiliar with using multiple passdb's... Thanks, Charles

2 6

Shared inbox?
by Chris Ross 29 May '15

29 May '15

I'm running dovecot 2.2.16 on my FreeBSD mail server. I've read information on the wiki about setting up shared mailboxes, but I want to do something that isn't really coved by the instructions I was reading there. My son (now 7 years old) has an account on the system, but doesn't use it directly. But, for things he's interested in like Minecraft, and/or the local zoo, we have given out his email address in a small number of places. What I would like to set up, both for now while he's not actually ever reading his email himself, and perhaps even for the future when we teach and/or allow for that, is for my wife and I to be able to "view" his inbox from our accounts. The instructions for setting up shared folders all are written so that they're secondary folders to all accounts. Is there a way to either (a) configure sharing someone elses Inbox by other accounts, or (b) setting up a separately configured shared folder to _act_ as the inbox for a single account? Thanks. Any suggestions to achieve the above described end goal would be appreciated. - Chris

3 6

Creating IMAP folders/subfolders with Thunderbird
by Alex Regan 29 May '15

29 May '15

Hi, I have dovecot-2.2.15 on fedora21 with Thunderbird and having some difficulty creating subfolders and deleting folders. Creating subfolders results in a folder at the root with a caret instead of a slash called folder^subfolder with an entry in .subscriptions with that name, instead of a new folder under the directory. I'm also unable to delete any folders. The command from within Thunderbird is just completely ignored. Any idea what's happening here? Thanks, Alex

2 2

X-UID in mail header is removed?
by mkawada＠redhat.com 28 May '15

28 May '15

Dear Dovecot Mailing List, I have 2 questions regarding dovecot and would very much appreciate if you would kindly give me helps. <Question 1> Is 'X-UID' no longer shown in mail header via pop3? I have checked with the following 3 version of dovecot packages in order to make sure if a message sent by dovecot have 'X-UID' in its mail header, and the result is that only "dovecot-0.99.11-10.EL4" shows 'X-UID' and the other ones do not(Please see the result written in the second half of this mail). <Question 2> Is 'X-UID' used for checking if a message has already been sent to a user so that he never gets any duplicated mails that are already in his mbox? The reason why I am asking this here is that I am working on a problem that a user sometimes gets a duplicated mail from dovecot if the user keeps mails on the server as its settings. I actually thought this kind of thing would happen if the 'UIDL' gets corrupted or changed for some reasons. However, it is said that this issue never happened in using "dovecot-0.99.11-10.EL4" which shows 'X-UID' in mail header and in using "dovecot-2.0.9-8.el6_6.4" which does not show 'X-UID', the issue happens sometimes. Thus, I would like information indicating what is exactly used to avoid getting any duplicated messages while downloading a message via pop3 from dovecot. Here is the test result I checked: (dovecot-0.99.11-10.EL4) ]# telnet localhost 110 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. +OK dovecot ready. user test +OK pass password +OK Logged in. list +OK 1 messages: 1 786 . RETR 1 +OK 786 octets Return-Path: <root(a)localhost.localdomain> Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.1/8.13.1) with ESMTP id t4S4dBcu006057 for <test(a)localhost.localdomain>; Thu, 28 May 2015 13:39:11 +0900 Received: (from root@localhost) by localhost.localdomain (8.13.1/8.13.1/Submit) id t4S4dB6u006056 for test; Thu, 28 May 2015 13:39:11 +0900 Date: Thu, 28 May 2015 13:39:11 +0900 From: root <root(a)localhost.localdomain> Message-Id: <201505280439.t4S4dB6u006056(a)localhost.localdomain> To: test(a)localhost.localdomain Subject: test mail X-IMAPbase: 1432787986 1 Status: O X-UID: 1 <--X-UID shown here Content-Length: 5 X-Keywords: test . UIDL +OK 1 1432787986.1 (dovecot-1.0.7-9.el5_11.4) ]# telnet localhost 110 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. +OK Dovecot ready. user test +OK pass password +OK Logged in. list +OK 1 messages: 1 606 . RETR 1 +OK 606 octets Return-Path: <root(a)localhost.localdomain> Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.8/8.13.8) with ESMTP id t4S27gBo007199 for <test(a)localhost.localdomain>; Thu, 28 May 2015 11:07:42 +0900 Received: (from root@localhost) by localhost.localdomain (8.13.8/8.13.8/Submit) id t4S27fXd007197 for test; Thu, 28 May 2015 11:07:41 +0900 Date: Thu, 28 May 2015 11:07:41 +0900 From: root <root(a)localhost.localdomain> Message-Id: <201505280207.t4S27fXd007197(a)localhost.localdomain> To: test(a)localhost.localdomain Subject: testmail test . UIDL +OK 1 0000000155667888 . (dovecot-2.0.9-8.el6_6.4) ]# telnet localhost 110 Trying ::1... telnet: connect to address ::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK Dovecot ready. user test +OK pass password +OK Logged in. list +OK 1 messages: 1 605 . RETR 1 +OK 605 octets Return-Path: <root(a)localhost.localdomain> X-Original-To: test Delivered-To: test(a)localhost.localdomain Received: by localhost.localdomain (Postfix, from userid 0) id 3629F4336A; Wed, 27 May 2015 11:34:39 +0900 (JST) Date: Wed, 27 May 2015 11:34:39 +0900 To: test(a)localhost.localdomain Subject: test mail User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20150527023439.3629F4336A(a)localhost.localdomain> From: root(a)localhost.localdomain (root) test . UIDL +OK 1 0000000155652c77 Thanks, Masaharu Kawada

1 0

Re: FREAK/Logjam, and SSL protocols to use
by Jacques Distler 27 May '15

27 May '15

> For a given computational effort, you get the most bang-for-the-buck by > choosing large parameters (and checking very carefully that they are > "safe") rather than smaller parameters (and/or checking them less > carefully) which you then regenerate. This discussion (on the OpenSSH mailing list) http://marc.info/?t=143221614200001 may be helpful to those thinking about this.

1 0

Re: FREAK/Logjam, and SSL protocols to use
by Jacques Distler 27 May '15

27 May '15

>But when you write NOT to regenerate, are you saying that using larger primes makes regenerating unnecessary, or are you telling us that it's somehow harmful? For a given computational effort, you get the most bang-for-the-buck by choosing large parameters (and checking very carefully that they are "safe") rather than smaller parameters (and/or checking them less carefully) which you then regenerate. Every time you regenerate, there's a small (but finite) probability that the new parameters are actually unsafe. You'd do better using those CPU cycles to improve the proof that your original set of parameters was safe (admittedly, no one actually does this), rather than generating a new set. Remember, the DH parameters (p,g) are NOT secret; they are transmitted in the clear everytime. As long as you're using Ephemeral Diffie-Hellman (choosing new exponents, a and b, for each session) with large safe DH parameters, it's hard to think of a threat model where you improve the security AT ALL by regenerating the DH parameters.

1 0

Re: FREAK/Logjam, and SSL protocols to use
by Jacques Distler 27 May '15

27 May '15

>It is not at this point emphasized anywhere, including on weakdh.org, that it is actually of high importance to regenerate your DH parameters frequently. That's not really correct. If you're using a prime of length at least 2048 bits, then the corresponding discrete-log problem is well-beyond the pre-computation ability of the NSA (or anyone else). It is computationally intensive to generate such large primes, p (and corresponding base parameter, g). You need to ensure that p is actually prime (the costly step [1]) and that g is primitive. Which is why most implementations have used shorter (<= 1024 bit) primes. Using shorter primes, and regenerating DH parameters at regular intervals, is only a linear-time improvement. By contrast, generating longer DH parameters (without bothering to regenerate) is an EXPONENTIAL improvement in security. So the best setting is to set ssl_dh_parameters_length as large as feasible ([2] recommends 2048 bits), and NOT to regenerate. [1] http://en.wikipedia.org/wiki/Miller%E2%80%93Rabin_primality_test [2] https://weakdh.org/sysadmin.html

2 1

FREAK/Logjam, and SSL protocols to use
by Ron Leach 27 May '15

27 May '15

List, good afternoon, I was reading up on a TLS Diffie Hellman protocol weakness described here https://weakdh.org/sysadmin.html which is similar to the earlier FREAK attack, and can result in downgrade of cipher suites. Part of the solution workaround that the researchers describe for Dovecot here https://weakdh.org/sysadmin.html includes altering DH parameters length to 2048, and re-specifying the allowable cipher suites - they give their suggestion. But the researchers make no comment on the allowable protocols that, in Dovecot, are controlled in 10-ssl.conf in the stanza headed # SSL protocols to use #ssl_protocols = !SSLv2 I couldn't find any advice on up-to-date SSL/TLS protocol settings in the Dovecot wiki, either (I looked in http://wiki2.dovecot.org/SSL/DovecotConfiguration ). At the moment our installation is using only the default settings for allowed protocols; I'm not sure what those defaults might be, but our 10-ssl.conf may only be disallowing SSLv2, if the 'example' entry is the default. We're running 2.2.15, and are due to upgrade to 2.2.18 shortly; quite possibly the defaults differ in a more recent release. What SSL protocols do folk on the list recommend should be allowed in Dovecot these days? (Actually, I mean which protocols really 'must' be disallowed?) regards, Ron

5 10

/etc/ssl/certs/dovecot.pem erased by OpenSuse's update mechanism
by Wolfgang Gross 27 May '15

27 May '15

Hi, this is not a genuine Dovecot bug, more a nuisance. It applies to OpenSuse 13.2 but maybe also to other Linux's. The standard installation of Dovecot (especially 10-ssl.conf) places the certificate dovecot.pem in /etc/ssl/certs. Sometimes during updates does OpenSuse renew all certificates in /etc/ssl/certs and erases dovecot.pem. This blocks further access to the mailbox. I found a similar report here: https://bbs.archlinux.de/viewtopic.php?id=27288 Workaround: Move dovecot.pem to another directory and change 10-ssl.conf accordingly. Regards Wolfgang Gross -- Dr. W. Gross Sektion Chirurgische Forschung Klinik für Allgemein-, Viszeral- und Transplantationschirurgie Universitätsklinikum Heidelberg Im Neuenheimer Feld 365, D-69120 Heidelberg, Germany Tel. ++49 (0)6221/566392, Fax: ++49 (0)6221/566402 WGross(a)uni-hd.de

3 3