- dovecot - dovecot.org

[Dovecot] ssl_require_crl does not work as expected
by dovecot.pkoch＠dfgh.net 08 Apr '13

08 Apr '13

Hi I'm trying to use dovecot with client certificates. We produce our certificates with our on CA and we do NOT use certificate revocation lists. So I put "ssl_require_crl = no" into 10-ssl.conf. I did not find a solution neither in the wiki nor somewhere else, so I finally started to read the source. My impression is that openssl will always try to use CRLs. If "ssl_require_crl = no" dovecot will use CRLs but tries to ignore openssl error codes X509_V_ERR_UNABLE_TO_GET_CRL and X509_V_ERR_CRL_HAS_EXPIRED. This is done in ssl_verify_client_cert() in ssl-proxy-openssl.c line 871, namely i_info("proxy=%d, require_crl=%d, error=%d", proxy->client_proxy, proxy->set->ssl_require_crl, ctx->error ); if (proxy->client_proxy && !proxy->set->ssl_require_crl && (ctx->error == X509_V_ERR_UNABLE_TO_GET_CRL || ctx->error == X509_V_ERR_CRL_HAS_EXPIRED)) { /* no CRL given with the CA list. don't worry about it. */ preverify_ok = 1; } With my setup proxy->client_proxy is 0. I added the i_info() to check this and with this modification my syslog shows: Apr 7 13:01:16 d600 dovecot: master: Dovecot v2.1.15 starting up (core dumps disabled) Apr 7 13:01:21 d600 dovecot: auth: Debug: Loading modules from directory: /usr/dovecot/lib/dovecot/auth Apr 7 13:01:21 d600 dovecot: auth: Debug: auth client connected (pid=26175) Apr 7 13:01:22 d600 dovecot: imap-login: proxy=0, require_crl=0, error=3 Apr 7 13:01:22 d600 dovecot: imap-login: Invalid certificate: unable to get certificate CRL: /CN=...user cert.../C=DE Apr 7 13:01:22 d600 dovecot: imap-login: proxy=0, require_crl=0, error=3 Apr 7 13:01:22 d600 dovecot: imap-login: Invalid certificate: unable to get certificate CRL: /CN=...intermedieate cert.../C=DE Apr 7 13:01:22 d600 dovecot: imap-login: proxy=0, require_crl=0, error=3 Apr 7 13:01:22 d600 dovecot: imap-login: Invalid certificate: unable to get certificate CRL: /CN=Root-CA.../C=DE I dont know what the proxy-stuff is about so instead of ignoring CRL-related errors I tried to disable CRL-checking. I therefore commented out two lines in ssl_proxy_ctx_verify_client() in ssl-proxy-openssl.c line 1004, namely: // X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK | // X509_V_FLAG_CRL_CHECK_ALL); This tells OpenSSL not to check CRLs. Of course in production code this should be done only if "ssl_require_crl = no". Similar code is contained in iostream-openssl-context.c, namely in routine ssl_iostream_ctx_verify_remote_cert() Is this a bug? Peter

2 1

[Dovecot] client limit and STARTTLS
by David Benfell 08 Apr '13

08 Apr '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm migrating from one system to another. Both are Arch Linux, but copying the configurations and just modifying them for IP addresses and hostnames didn't work. Here's doveconf -n # 2.1.15: /etc/dovecot/dovecot.conf doveconf: Warning: service auth { client_limit=256 } is lower than required under max. load (3072) doveconf: Warning: service anvil { client_limit=256 } is lower than required under max. load (2051) # OS: Linux 3.8.4-1-ARCH x86_64 base_dir = /var/run/dovecot/ default_client_limit = 256 default_process_limit = 1024 login_trusted_networks = 10.8.0.0/16 127.0.0.0/8 mail_location = maildir:~/Maildir mail_max_userip_connections = 30 passdb { args = failure_show_msg=yes driver = pam } service auth { unix_listener /var/spool/postfix/private/auth { mode = 0666 } } ssl_cert = </big/www/ssl/www.cybernude.org_publickey.pem ssl_key = </big/www/ssl/www.cybernude.org_privatekey.pem userdb { driver = passwd } Obvious first question: I can't figure out how to make dovecot happy with the client and process limits. I'm not terribly worried about going overboard here, though I have a very small number of users; the migration is to a much more capable system. But I would like to stop looking at the warning. It doesn't seem to matter what I put where--it keeps complaining. Second question: STARTTLS isn't working. What am I missing? Sorry if this is something that should be obvious; I'm fighting a similar battle with postfix and I'm being pushed around the bend while I really need to be working on other things. Thanks! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRXy6nAAoJELJhbl/uPb4SsTAQALIkmDwCwPlCNPtJr482lVNj vsNHX4TvTy0Xu4adtxFqJQM30EoEpu4A983CTm81jUFYKqDIBRJ3SAVOGf58lCQ1 uJhoyL0yhCaO9Zh7WZKdmhB+Jnek2+Rz2cpfOP4VseLL7Lg3OIwI4K/YiDAIcwnW do/tvuJEL6SDDcDA3gOjDJ7gkykg34tJ02nnG65Yau0y563FT7npXKFnwGSn1X0+ GTFUwpZx5xp90eUZBLoTBPcnXohKlWhYxa2POHgm7eraK8k+aD9/2zlThQL6/qIx HQKcSkZjB1CTgKGysp+msaR/gS5HiHILadB3opP8p7baGNG9jhifKE6LJavREH8p PsxxCpTnf8d+xbbJVeDx6cyz7NQ8rNLals1qtPLAY4F04Uh400FjJov/dJruBISZ QvASZPOtyZHuswUnSTtX22WOg2QIvyO5GyzqPGZ/0+MtgbtJxwizsyCTEFuTkq+r RvsW1cltVsDKCFCCcjrkRzWu+xbDrkX42tNUnhi4YSJ5wcKQMRiqQBTtyCYT88sy Ws9WtNaElOERxQeydmizvxIuFIoLapdPtfyRDSGoDOo0Cnq/QSIzvQNdOVbqqSBt hcIVDNHTw8O5UfOhhbo+YT8QIBwD8J/uPxLfV72ep7nQBJh8XOymHJXGtQR8+H4x 6aey6+bafQ/YHtuS63bz =4qNn -----END PGP SIGNATURE-----

4 4

[Dovecot] v2.2.rc6 released
by Timo Sirainen 08 Apr '13

08 Apr '13

http://dovecot.org/releases/2.2/rc/dovecot-2.2.rc6.tar.gz http://dovecot.org/releases/2.2/rc/dovecot-2.2.rc6.tar.gz.sig Some more fixes to bugs I noticed today while trying out some new things in production. Note especially the replicator-doveadm socket change, see http://wiki2.dovecot.org/Replication for how to configure it. This change allowed local replicator to notify the remote replicator about user being synced. * replicator: Don't create replicator-doveadm socket by default. This way doveadm replicator commands don't accidentally start an unconfigured replicator server. + replicator: Have remote dsync notify the remote replicator that a user was just synced. This way the replicators are kept roughly in sync. + Added ssl_client_ca_file to specify the CA certs as a file. This is needed (instead of ssl_client_ca_dir) in RedHat-based systems. + Added "doveadm fs" commands, mainly to debug lib-fs backends. - Mailbox list indexes weren't using proper file permissions based on the root directory.

2 2

[Dovecot] mdbox and folders containing both messages and sub-folders
by Rich Wales 08 Apr '13

08 Apr '13

I've got Dovecot 2.2r5 (Ubuntu package version 2:2.2.0~rc5-0~auto+1 from the "testing-auto/dovecot-2.2" repository on xi.rename-it.nl) running on a brand-new Ubuntu 12.04.2 server. I'm trying to configure Dovecot (using the "mdbox" mailbox format) to allow folders to contain both messages and sub-folders. However, it's not working consistently. I need to have folders with both messages and sub-folders because I'm trying to migrate mail from an existing (but soon-to-be-retired) Cyrus server, and the existing body of mail has folders of this sort. I'm currently using the following configuration line: mail_location = mdbox:~/mdbox:DIRNAME=.indexes:INDEX=~/mdbox/indexes and am using the Larch program to do an IMAP-to-IMAP copy of one of my family member's mail from the old Cyrus server to the new Dovecot server. When I examine the "mailboxes" directory tree, I see some directories that (correctly) contain both the renamed ".indexes" directory and also directories for IMAP subfolders. However, the Larch output is showing many errors of the form "mailbox cannot contain messages", and some of the messages could not be migrated because of this problem. Am I doing something wrong? Or is the "folders containing both messages and sub-folders" feature simply broken for the "mdbox" format -- meaning presumably that I'll be forced either to use the Maildir format, or else abandon Dovecot entirely and install Cyrus on my new mail server instead? Rich Wales richw(a)richw.org

7 14

[Dovecot] autocreate mailbox but no sub folders
by Arnaud Abélard 07 Apr '13

07 Apr '13

Hello, We have been using lda_mailbox_autocreate to avoid to intialize empty mailboxes upon account creations. This does the job allright except that dovecot-lda is also allowed to autocreate sub folders which is a problem when using addresses extensions (adress+folder(a)domain.tld) It's easy for a malicious user to flood a mailbox with tons of subfolders. Is there a way to tell dovecot-lda it can only create the initial mailbox and maybe some special folders but nothing else? Thanks, Arnaud -- Arnaud Abélard jabber: arnaud.abelard(a)univ-nantes.fr / twitter: ArnY Administrateur Système DSI Université de Nantes -

2 1

[Dovecot] replicator/dsync over tcp
by Michael Grimm 07 Apr '13

07 Apr '13

Hi -- I am testing replicator/dsync over tcp, and I did run into some issues. First of all I did need to extend http://wiki2.dovecot.org/Replication to get dsync over tcp running without ssl: | # dsync over tcp default port | # | doveadm_port = 12345 | service doveadm { | # running dsync over tcp and using ssl | # added-->| user = vmail | inet_listener { added-->| address = 1.2.3.4 | port = 12345 | # ssl = yes | } | } | plugin { | # this host replicates to remote host | # | mail_replica = tcp:SERVER-A.TLD That didn't work ... | dovecot: doveadm(test): Error: doveadm_password not set, can't authenticate to remote server ... thus, I needed to add: added-->| local 1.2.3.4 { added-->| # password for client authentication by doveadm server added-->| # added-->| doveadm_password = secret added-->| # allow client to only use specified list of commands (default is all): added-->| # added-->| #doveadm_allowed_commands = added-->| } 1. Question: may one include "secret" from a file? Well, that runs like a charm! Now, I did try to add ssl by activating "ssl = yes" in 'service doveadm' (see above) and adding ... | # used by replicator/dsync over tcp | # | ssl_client_ca_dir = /<path-to>/ssl/certs ... and ... | mail_replica = tcps:SERVER-A.TLD But, this didn't work (logfile at remote server): | dovecot: doveadm(test): Invalid certificate: self signed certificate: /OU=dovecot server/CN=OTHER-NAME.TLD/emailAddress=postmaster(a)OTHER-NAME.TLD | dovecot: doveadm(test): Error: SERVER-A.TLD: Received invalid SSL certificate | dovecot: doveadm(test): Error: sync: Disconnected from remote The OTHER-NAME.TLD is served by my additional settings used by my MUAs: | ssl_cert = </<path-to>/ssl/certs/OTHER-NAME.TLD.pem | ssl_key = </<path-to>/ssl/private/OTHER-NAME.TLD.pem I did supply SERVER-A.TLD certs and private certificates at both servers as well, but dovecot seems to use those of OTHER-NAME.TLD for replicator/dsync instead :-( 2. Question: May I config the certificate that should be used for replicator/dsync and that might be different from those used by my MUAs (other then pointing to '/<path-to>/ssl/certs')? I am quite sure that I screwed my config somehow, but I cannot find the cause. Thus, someone? Thanks, and with kind regards, Michael

2 4

[Dovecot] v2.1.16 released
by Timo Sirainen 07 Apr '13

07 Apr '13

http://dovecot.org/releases/2.1/dovecot-2.1.16.tar.gz http://dovecot.org/releases/2.1/dovecot-2.1.16.tar.gz.sig + Added quota-status policy service for Postfix + Added "doveadm batch" command to run multiple commands before moving onto the next user (useful only with -A and -u <usermask>) + Added forwards compatibility for v2.2 index files - mdbox: Index rebuilding crashed in some situations - Fixed a race condition with setting \Recent flags - Fixed a crash when decoding a specific message (decoding is done for SEARCH TEXT/BODY and with full text search indexing, so this couldn't fully DoS a user)

7 24

Re: [Dovecot] [Dovecot-de] Dovecot Quota via policy service abfragen
by Andreas Meyer 07 Apr '13

07 Apr '13

Ralf Hildebrandt <Ralf.Hildebrandt(a)charite.de> wrote: > * Andreas Meyer <anmeyer(a)anup.de>: > > > Habe ich jetzt neben quota_grace = 10%% auch rausgenommen. > > Gut. > > > Apr 7 19:38:35 delta postfix/smtpd[23037]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201] > > Apr 7 19:38:36 delta postfix/smtpd[23037]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201] > > Apr 7 19:38:36 delta postfix/smtpd[23037]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits) > > Apr 7 19:38:37 delta postfix/smtpd[23037]: NOQUEUE: client=p54B32BC9.dip.t-dialin.net[84.179.43.201], sasl_method=CRAM-MD5, sasl_username=anmeyer(a)anup.de > > Apr 7 19:39:01 delta postfix/smtpd[23139]: connect from localhost[127.0.0.1] > > Apr 7 19:39:01 delta postfix/smtpd[23139]: 9C1BA1B30FB0: client=localhost[127.0.0.1] > > Apr 7 19:39:01 delta postfix/cleanup[23142]: 9C1BA1B30FB0: message-id=<20130407193818.62d8c328(a)itxnew.bitcorner.intern> > > Apr 7 19:39:01 delta postfix/qmgr[22234]: 9C1BA1B30FB0: from=<anmeyer(a)anup.de>, size=1492149, nrcpt=1 (queue active) > > Apr 7 19:39:01 delta postfix/smtpd[23139]: disconnect from localhost[127.0.0.1] > > Apr 7 19:39:02 delta postfix/smtpd[23037]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201] > > Apr 7 19:39:02 delta postfix/pipe[23143]: 9C1BA1B30FB0: to=<miles(a)anup.de>, relay=dovecot, delay=0.56, delays=0.33/0/0/0.23, dsn=4.3.0, status=deferred (temporary failure) > > Na dann sind deine Restrictions falsch und die Mail wird "OK"'ed bevor > der Policy Server gefragt wird. > > > Ich habe warn_if_reject check_policy_service inet:127.0.0.1:12340 > > ziemlich am Anfang der recipient_restrictions gesetzt nachdem ich > > den check am Ende hatte noch nach postgrey. > > > > smtpd_recipient_restrictions = > > ---> hier einbauen <--- > ist ja nur zum Test > > > check_sender_access hash:/etc/postfix/access_sender, > > permit_mynetworks, > > permit_sasl_authenticated, > > reject_invalid_helo_hostname, > > reject_unlisted_recipient, > > warn_if_reject check_policy_service inet:127.0.0.1:12340 > > reject_unknown_sender_domain, > > check_sender_access pcre:/etc/postfix/umlaute.pcre, > > check_recipient_access pcre:/etc/postfix/umlaute.pcre, > > reject_unauth_destination, > > reject_rbl_client bl.spamcop.net, > > reject_rbl_client zen.spamhaus.org, > > check_client_access cidr:/etc/postfix/client.cidr, > > check_policy_service inet:127.0.0.1:10023 That did the trick! The order of the recipient_restricitons was wrong. Apr 7 20:24:55 delta postfix/smtpd[23806]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 20:24:55 delta postfix/smtpd[23806]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 20:24:56 delta postfix/smtpd[23806]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits) Apr 7 20:24:56 delta postfix/smtpd[23806]: NOQUEUE: reject: RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201]: 552 5.2.2 <miles(a)anup.de>: Recipient address rejected: Quota exceeded (mailbox for user is full); from=<anmeyer(a)anup.de> to=<miles(a)anup.de> proto=ESMTP helo=<itxnew.bitcorner.intern> Apr 7 20:24:56 delta postfix/smtpd[23806]: lost connection after RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 20:24:56 delta postfix/smtpd[23806]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201] The MUA does not get rid of the mail, when it would exceed the quota. But now the next problem. I cannot send this mail and get the following with smtpd_recipient_restrictions = check_policy_service inet:127.0.0.1:12340 check_sender_access hash:/etc/postfix/access_sender, permit_mynetworks, permit_sasl_authenticated, .... Apr 7 20:31:43 delta postfix/smtpd[23820]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 20:31:44 delta postfix/smtpd[23820]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 20:31:45 delta postfix/smtpd[23820]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits) Apr 7 20:31:46 delta postfix/smtpd[23820]: warning: problem talking to server 127.0.0.1:12340: Success Apr 7 20:31:46 delta postfix/smtpd[23820]: NOQUEUE: reject: RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201]: 451 4.3.5 Server configuration problem; from=<anmeyer(a)anup.de> to=<dovecot(a)listen.jpberlin.de> proto=ESMTP helo=<itxnew.bitcorner.intern> Apr 7 20:31:46 delta postfix/smtpd[23820]: lost connection after RCPT from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 20:31:46 delta postfix/smtpd[23820]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201] the mail is not sent out. I deactivated the check to get sent mail sent. Andreas

1 0

[Dovecot] IDLE and inactivity
by Andreas Meyer 07 Apr '13

07 Apr '13

Good day! Apr 07 10:59:40 imap(anmeyer(a)anup.de): Info: Disconnected: Disconnected in IDLE in=725 out=2546 Apr 07 10:59:59 imap(anmeyer(a)anup.de): Info: Disconnected for inactivity in=952 out=25789 Please someone explain to me the IDLE state and the inactivity state an what the numbers at in= and out= means! Andreas

2 1

Re: [Dovecot] [Dovecot-de] Dovecot Quota via policy service abfragen
by Andreas Meyer 07 Apr '13

07 Apr '13

Hallo Waffenmeister! Ralf Hildebrandt <Ralf.Hildebrandt(a)charite.de> wrote: > > Apr 7 14:07:52 delta postfix/qmgr[19078]: 1D8921B31260: from=<anmeyer(a)anup.de>, size=1492149, nrcpt=1 (queue active) > > Apr 7 14:07:53 delta postfix/pipe[19091]: 1D8921B31260: to=<miles(a)anup.de>, relay=dovecot, delay=2542, delays=2542/0.01/0/0.29, dsn=4.3.0, status=deferred (temporary failure) > > Ich sehe hier nur einen Fehler vom transport "dovecot". > > > plugin { > > quota = maildir:User quota > > quota_grace = 10%% > > quota_rule = *:storage=500MB > > quota_rule2 = Trash:storage=+10%% > > > > quota_status_success = DUNNO > > quota_status_nouser = DUNNO > > quota_status_overquota = 552 5.2.2 Mailbox is full / Mailbox ist voll > > Lass mal das quota_status_overquota feld weg. Habe ich jetzt neben quota_grace = 10%% auch rausgenommen. Apr 7 19:38:35 delta postfix/smtpd[23037]: connect from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 19:38:36 delta postfix/smtpd[23037]: setting up TLS connection from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 19:38:36 delta postfix/smtpd[23037]: TLS connection established from p54B32BC9.dip.t-dialin.net[84.179.43.201]: TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits) Apr 7 19:38:37 delta postfix/smtpd[23037]: NOQUEUE: client=p54B32BC9.dip.t-dialin.net[84.179.43.201], sasl_method=CRAM-MD5, sasl_username=anmeyer(a)anup.de Apr 7 19:39:01 delta postfix/smtpd[23139]: connect from localhost[127.0.0.1] Apr 7 19:39:01 delta postfix/smtpd[23139]: 9C1BA1B30FB0: client=localhost[127.0.0.1] Apr 7 19:39:01 delta postfix/cleanup[23142]: 9C1BA1B30FB0: message-id=<20130407193818.62d8c328(a)itxnew.bitcorner.intern> Apr 7 19:39:01 delta postfix/qmgr[22234]: 9C1BA1B30FB0: from=<anmeyer(a)anup.de>, size=1492149, nrcpt=1 (queue active) Apr 7 19:39:01 delta postfix/smtpd[23139]: disconnect from localhost[127.0.0.1] Apr 7 19:39:02 delta postfix/smtpd[23037]: disconnect from p54B32BC9.dip.t-dialin.net[84.179.43.201] Apr 7 19:39:02 delta postfix/pipe[23143]: 9C1BA1B30FB0: to=<miles(a)anup.de>, relay=dovecot, delay=0.56, delays=0.33/0/0/0.23, dsn=4.3.0, status=deferred (temporary failure) > > Also ich vermisse das reject-warning von postfix und es hat auch nicht den > > Anschein, dass postfix den Status der Quota bei dovecot über port 12340 > > abfrägt. > > Naja, vielleicht steht es an der falschen Stelle in den Restrictions! > Das muss passieren BEVOR irgendwas ein OK zurückgibt. Ich habe warn_if_reject check_policy_service inet:127.0.0.1:12340 ziemlich am Anfang der recipient_restrictions gesetzt nachdem ich den check am Ende hatte noch nach postgrey. smtpd_recipient_restrictions = check_sender_access hash:/etc/postfix/access_sender, permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_unlisted_recipient, warn_if_reject check_policy_service inet:127.0.0.1:12340 reject_unknown_sender_domain, check_sender_access pcre:/etc/postfix/umlaute.pcre, check_recipient_access pcre:/etc/postfix/umlaute.pcre, reject_unauth_destination, reject_rbl_client bl.spamcop.net, reject_rbl_client zen.spamhaus.org, check_client_access cidr:/etc/postfix/client.cidr, check_policy_service inet:127.0.0.1:10023 Andreas

1 0