- dovecot - dovecot.org

how to run dovecot imap on separate server from postfix?
by Robert Fantini 18 Feb '15

18 Feb '15

Hello we are using version 2.2.13 on debian. currently imap runs on the same system as postfix , spamassassin and other mail related software. I'd like to move dovecot imapd and mail storage to its own system. I've search google and wiki and could not see how to do so. could someone please point me in the direction to that done? I like reading documentation.. here is more info on our set up: postfix: # grep dovecot /etc/postfix/* /etc/postfix/main.cf:mailbox_transport = lmtp:unix:private/dovecot-lmtp /etc/postfix/main.cf:smtpd_sasl_type = dovecot kind regards Rob Fantini

2 9

Permissions for shared mail don't work
by Damien Desfontaines 17 Feb '15

17 Feb '15

Hello, (Sorry if you already received this mail. I sent it without having subscribed to the list, but I never got any confirmation; so I assumed it has been filtered by the anti-spam or something.) I'm using dovecot v.2.1.7 on Debian Sid, and the output of dovecot -n is available here: http://paste.fulltxt.net/C-O I'm trying to make the mailbox of (system) user "spam" available to user "ted". I followed these instructions: http://wiki2.dovecot.org/SharedMailboxes/Permissions and it doesn't seem to work. To be more precise: - I manually (and recursively) changed the permissions of all files in ~spam/Mail to 660 (and 770 for the directories); - I manually (and recursively) changed the group owner of everything in ~spam/Mail to "mailperso", where "mailperso" is a group whose users are spam and ted; - I added « mail_access_groups=mailperso » into my dovecot config; - and I restarted dovecot. But still, when I send a new email to spam, it appears as being owned by group "spam" and having permissions set to 600, so I can't access it with user "ted". I also tried to set the setgid bit for ~spam/Mail, it didn't change anything, and when I recursively set the setgid for all subdirectories of ~spam/Mail, it gives new mails the correct group (mailperso) but not the correct permissions. Have I missed something, or is this a bug? Thanks in advance and best regards, Damien

3 8

Help with archive server
by Joy 17 Feb '15

17 Feb '15

Hi, I want to build a system where 6 months old mail to be moved to archive server to keep my mailbox clean and fast. Is there any way to achieve the same using any pre-built binary shipped with dovecot ? Thanks and Regards Joy

2 2

Re: Re: Cannot delete folders from Maildir in only one account
by Christian Vielhauer 17 Feb '15

17 Feb '15

Hi Steffen thanks for your reply. I found that permissions of some folders are different than others… After chmod all permissions to the same go= permissions, it works. No matter what happens to generate different permissions for only this one account. Because all other accounts are correct. I will have a look at this from time to time. As soon it not happens agains this thread is solved. On Mon, 16 Feb 2015, Christian Vielhauer wrote: > I try to delete the folder „test" from Thunderbird 31.4.0 (Win), Webmail (Sogo 2.2.16), or Mail 8.2 (Mac Yosemite), but I am not able to delete in this account. > Nevertheless I am able to create new folders. These new folders are not deleteable, too. What's the returned description sctring, if you try to delete the folder manually via telnet? > dovecot 2.2.9 on Ubuntu 14.04 LTS 64-bit > > In /var/log/mail.{err,log} I cannot see any errors. What does Dovecot log? It usually logs to somewhere else. > In another account it works without any problems. (create and delete folders) - -- Steffen Kaiser

1 0

auth: Fatal: No passdbs specified in configuration file
by rub zorghy 17 Feb '15

17 Feb '15

Hi, I upgraded to 20150213 (f10725a5eed8+). I chose LDAP as the authentication source for Dovecot. Compilation succeeds. Starting dovecot from command line : /usr/local/sbin/dovecot -c /usr/local/etc/dovecot/ The error log contains : "dovecot: auth: Fatal: No passdbs specified in configuration file. PLAIN mechanism needs one" It works properly with Dovecot 2.0.9. Any clues or suggestions, anything I could try...? Thanks, This is the output of dovecot -n: # 20150213 (f10725a5eed8+): /usr/local/etc/dovecot/dovecot.conf # OS: Linux 2.6.32-504.el6.x86_64 x86_64 Red Hat Enterprise Linux Server release 6.6 (Santiago) doveconf: Warning: Dovecot was last started using /usr/local/etc/dovecot/, but this config is /usr/local/etc/dovecot/dovecot.conf auth_debug = yes auth_debug_passwords = yes auth_master_user_separator = * auth_mechanisms = plain login auth_verbose = yes disable_plaintext_auth = no mail_debug = yes mail_gid = 5000 mail_location = maildir:~/Maildir:LAYOUT=fs mail_plugins = " quota acl" mail_uid = 5000 mbox_write_locks = fcntl namespace { list = children location = maildir:/store/vmail/public:LAYOUT=fs prefix = public/ separator = / subscriptions = no type = public } namespace inbox { inbox = yes location = prefix = } passdb { args = /usr/local/etc/dovecot/master-users driver = passwd-file master = yes pass = yes } passdb { args = /usr/local/etc/dovecot/dovecot-ldap.conf.ext driver = ldap } plugin { quota = maildir quota_rule = *:storage=50M quota_rule2 = Trash:storage=+5M quota_warning = storage=95%% quota-warning 95 %u quota_warning2 = storage=80%% quota-warning 80 %u } service auth { client_limit = 9516 unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-userdb { group = vmail mode = 0660 user = vmail } } service imap-login { process_min_avail = 2 service_count = 0 } service imap { process_limit = 8192 } service quota-warning { executable = script /usr/local/bin/quota-warning.sh unix_listener quota-warning { user = vmail } user = vmail } ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_key = </etc/pki/dovecot/private/dovecot.pem syslog_facility = local5 userdb { args = /usr/local/etc/dovecot/dovecot-ldap.conf.ext driver = ldap } verbose_ssl = yes

2 1

Cannot delete folders from Maildir in only one account
by Christian Vielhauer 17 Feb '15

17 Feb '15

Hi I try to delete the folder „test" from Thunderbird 31.4.0 (Win), Webmail (Sogo 2.2.16), or Mail 8.2 (Mac Yosemite), but I am not able to delete in this account. Nevertheless I am able to create new folders. These new folders are not deleteable, too. dovecot 2.2.9 on Ubuntu 14.04 LTS 64-bit In /var/log/mail.{err,log} I cannot see any errors. In another account it works without any problems. (create and delete folders) Have you any hint, I can try? Chris

2 1

Dovecot fsync question
by Christian Binder Stadt Freilassing 17 Feb '15

17 Feb '15

Hello, I followed these steps in http://wiki2.dovecot.org/MailLocation/LocalDisk # Default to no fsyncing mail_fsync = never protocol lda { # Enable fsyncing for LDA mail_fsync = optimized } protocol lmtp { # Enable fsyncing for LMTP mail_fsync = optimized } This gives quite a good performance, but I'm not sure about the risks. Does it mean that things like *put a Sent Mail to Sent folder *change status of mails really don't get synced to disk for a long time (hours??). Or do we talk about seconds and everything is fine when dirty pages get synced by the system. cat /proc/meminfo | grep 'Dirty' lets me assume that there are always just a few KB in the dirty pages and these are written to disk every few seconds. Are the dovecot "mail_fsync = never" transactions inclduded there? Thanks a lot! Christian

1 0

Re: /etc/ssl/certs/dovecot.pem erased by OpenSuse's update mechanism
by dovecot＠lists.killian.com 17 Feb '15

17 Feb '15

On 2015/2/16 16:28, Jochen Bern wrote: > On 02/16/2015 04:23 PM, Reindl Harald wrote: >>> "The CA file should contain the certificate(s) followed by the >>> matching CRL(s). Note that the CRLs are required to exist. For a >>> multi-level CA place the certificates in this order: >>> >>> Issuing CA cert >>> Issuing CA CRL >>> Intermediate CA cert >>> Intermediate CA CRL >>> Root CA cert >>> Root CA CRL" >> >> that is how you can and should build your PEM files for *every* SSL > ^^^^^^^ >> aware software > > NACK. I have set up CentOS 6 servers a little more than two years ago > with that format used for dovecot and OpenVPN, including verification > that the functionality was there. Last month we had a need to revoke a > client's certs and it turned out that OpenVPN had silently stopped > honoring the CRLs somewhere along the update path (dovecot still > enforces them). I had to QuickFix the OpenVPN config from the above > monolithic file over to a CApath > > https://www.openssl.org/docs/ssl/SSL_CTX_load_verify_locations.html#notes > > to successfully lock the disgraced client out. > > Regards, > J. Bern OpenVPN has --crl-verify that takes a file as well as a directory. I guess what you're saying is that accepts, but silently ignores the CRLs if put in the cert file. It would be nicest if all the software wanted things configured things the same way. Personally I like the way Dovecot does it, but having things be uniform would be even better. From my quick survey, a lot of the programs (or at least their documentation) doesn't support CRLs at all. Postfix wants multiple certificates specified by different .cf entries (it appears to not support CRLs--at least they aren't mentioned in documentation): smtpd_tls_cert_file smtpd_tls_key_file smtpd_tls_dcert_file smtpd_tls_dkey_file smtpd_tls_eccert_file smptd_tls_eckey_file smtpd_tls_CAfile Apache2.4 wants SSLCertificateFile SSLCertificateKeyFile repeated multiple times for different cert types. Making it worse, Apache2.4.8 wants the whole cert chain in the above, but earlier versions wanted SSLCertificateChainFile to have the non-leaf chain. Courier IMAP SSL wants TLS_CERTFILE specifying a file containing both the certificate and private key catenated. OpenVPN wants ca certificate chain used for signing.pem cert certificate.pem key privatekey.pem crl-verify crl.pem OpenLDAP appears similar to OpenVPN with (appears not to support CRLs): TLSCACertificatePath TLSCertificateFile TLSCertificateKeyFile Racoon wants (appears not to support CRLs): certificate_type x509 certfile keyfile ca_type x509 ca.pem But the man page doesn't talk about where the chain goes. So it appears one should generate the following file formats to satisfy all the software out there: 1. cert standalone (OpenVPN, Racoon, OpenLDAP, Postfix, Apache 2.4.7 and earlier) 2. cert chain (Apache 2.4.8 and later) 3. cert ca crl chain (Dovecot) 4. ca chain (OpenVPN, Racoon?, OpenLDAP, Postfix, Apache 2.4.7 and earlier) 5. crl chain (OpenVPN) 6. cert, key catenation (Courier IMAP) Getting all these configured the same way isn't going to happen, so I guess the next best thing would be a cookbook. Anyone know of one? -Earl

1 0

Re: Controlling inactivity timeout for IMAP
by Joseph Tam 17 Feb '15

17 Feb '15

Andr? Peters writes: > > I have a problem with a user who uses a wireless carrier that keeps > > changing his IP as he travels throughout the city. From the perspective > > of our dovecot IMAP server, the user keeps logging in from another IP, > > and after a short while, hits up against the mail_max_userip_connections > > limit. It takes 30 minutes before those orphaned connections times out. > > > > Is there any way to decrease the IMAP idle timeout other than to > > recompile dovecot with a new value? > > > > imap-common.h:#define CLIENT_IDLE_TIMEOUT_MSECS (60*30*1000) > > > > For example, will this work? > > > > service imap { > > idle_kill = 600 > > } > > I was following this in hope someone would answer. > > As a workaround I recommend to set up a POP3 connection with a low > polling interval (besides using a TCP Proxy...). I'll give that a try -- I'll probably still get the odd orphaned process if the client changed address in the middle of a POP session. To close this out, I'll relate my experiments to asnwer the question I posed above in case it's of use to someone. Changing pre-authentication timeouts. The default is 3 minutes hardcoded at diff -r -U0 a/src/lib-master/master-interface.h b/src/lib-master/master-interface.h --- a/src/lib-master/master-interface.h Mon Jun 2 04:50:10 2014 +++ b/src/lib-master/master-interface.h Sat Feb 14 18:41:39 2015 @@ -99,1 +99,1 @@ -#define MASTER_LOGIN_TIMEOUT_SECS (3*60) +#define MASTER_LOGIN_TIMEOUT_SECS (31) Changing it to 31s still seems overly generous, but you can not set it lower unless you also change the next define /* auth server should abort auth requests before that happens */ #define MASTER_AUTH_SERVER_TIMEOUT_SECS (MASTER_LOGIN_TIMEOUT_SECS - 30) I really don't understand what this is about, but if this becomes zero, authentication breaks. Maybe (MASTER_LOGIN_TIMEOUT_SECS>>1) would be a safer definition. $ date; netcat 127.0.0.1 143; date Mon Feb 16 15:23:44 EST 2015 * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Ready. * BYE Disconnected for inactivity. Mon Feb 16 15:24:15 EST 2015 Changing post-authentication IMAP idle timeout The default (RFC minimum) is 30 minutes, which can be changed here diff -r -U0 a/src/imap/imap-common.h b/src/imap/imap-common.h --- a/src/imap/imap-common.h Mon Jun 2 04:50:10 2014 +++ b/src/imap/imap-common.h Sat Feb 14 18:44:24 2015 @@ -5,1 +5,1 @@ -#define CLIENT_IDLE_TIMEOUT_MSECS (60*30*1000) +#define CLIENT_IDLE_TIMEOUT_MSECS (60*15*1000) I also tried changing it in dovecot.conf service imap { idle_kill = 630 } but after recompiling/reconfiguring with both options, idle_kill has no influence. $ date ; echo . login user password | netcat 127.0.0.1 143 ; date Mon Feb 16 15:47:10 EST 2015 * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS AUTH=PLAIN] Ready. . OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE] Logged in * BYE Disconnected for inactivity. Mon Feb 16 16:02:11 EST 2015 General notes: Dovecot is chock full of these ad-hoc/default/RFC timeout definitions. The interaction of these timeouts between dovecot's internal components as well as remote clients is complex, and could cause problems if you change them. For example, our webmail system opens persistent IMAP connections, and if you set dovecot's idle timeout less than the webmail's idle timeout, the user will get an annoying re-login requests. It would be nice if this problem of mobile WiFi mail readers acquiring (and abandoning) new IPs could be handled in a more gracious way (reaping on a expedited schedule or LRU basis), but unless you really have to and know what you are doing, I would suggest not modifying timeouts. Joseph Tam <jtam.home(a)gmail.com>

1 0

Re: /etc/ssl/certs/dovecot.pem erased by OpenSuse's update mechanism
by dovecot＠lists.killian.com 17 Feb '15

17 Feb '15

Why not /etc/dovecot/private? That's where I put my dovecot certs. Dovecot's needs are a bit different from other software, and so it is unclear whether the files won't be unique to it. For example, I haven't seen the following before I read it on the Dovecot wiki: "The CA file should contain the certificate(s) followed by the matching CRL(s). Note that the CRLs are required to exist. For a multi-level CA place the certificates in this order: Issuing CA cert Issuing CA CRL Intermediate CA cert Intermediate CA CRL Root CA cert Root CA CRL" On 2015/2/16 06:42, Wolfgang Gross wrote: > On 16 Feb 2015 at 21:59, Nick Edwards wrote: > >> This directory in later times is where more and more distros are >> putting system wide server CA type certs, most distros are moving to >> this path, so the package maintainer should fix their script, maybe to >> /etc/ssl/private or such. > > Maybe not in /etc/ssl/private for security reasons? > 10-ssl.conf uses the same file name for certificate and private key; better > change this, too. > >> >> On 2/16/15, Wolfgang Gross <WGross(a)uni-hd.de> wrote: >>> 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 >>>

3 2