- dovecot - dovecot.org

[Dovecot] Sieve-storage: couldn't find storage root directory
by Asai 15 Aug '13

15 Aug '13

Greetings, Using Dovecot 2.2.4. In my DSync logs, I'm getting the error message: Error: sieve-storage: couldn't find storage root directory; sieve_dir was left unconfigured and autodetection failed However, I have the following configuration set: plugin { sieve = /vmail/%d/%n/sievescript sieve_dir = /vmail/%d/%n/ } Please, if you have a moment, tell me what I'm doing wrong here. Thank you. -- --Asai

3 5

[Dovecot] Quota to use limits from LDAP and usage from FS
by Frank Steinberg 15 Aug '13

15 Aug '13

Hi, I'm new to Dovecot (switching from Cyrus). I'm using Dovecot 2.1.7 from Ubuntu 13.04. Maildir data is stored on a Linux ext4 filesystem with quotas. I would like to use mail quota in a way, so that the usage values are taken from the filesystem's quota system by the "fs" backend, while the per-user limits get read from LDAP. Due to debugging messages, it's my impression that reading the limits from LDAP works quite well when the user process starts, but when IMAP access actually takes place, the fs backend uses the filesystem's soft limits. Can anybody confirm this behavior or is there a way to achieve what I intend? -frank

1 0

[Dovecot] Dovecot mailbox in read-only mode, Permanentflags empty
by Tommi A 15 Aug '13

15 Aug '13

Hi, I have installed Postfix + Dovecot 2.2.5 on a Fresh Arch Linux server (using Arch Linux repository packages). When accessing mailbox through Dovecot IMAP, all user mailboxes are in READ-ONLY mode. Here is a snippet from IMAP telnet conversation (after successful login). a LIST "" "*" * LIST (\HasNoChildren) "." INBOX a OK List completed. a EXAMINE INBOX * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS ()] Read-only mailbox. * 1 EXISTS * 1 RECENT * OK [UNSEEN 1] First unseen. * OK [UIDVALIDITY 1376459543] UIDs valid * OK [UIDNEXT 2] Predicted next UID * OK [NOMODSEQ] No permanent modsequences a OK [READ-ONLY] Examine completed (0.000 secs). I can read the messages but trying to delete results in: a uid store 1 +flags.silent (\Seen \Deleted) a OK Store ignored with read-only mailbox. I have tried ALOT of different settings (mbox/maildir/acl) but nothing seems to help, also no error messages are found in any logfiles. I noticed from mailing list archive that Dovecot has had Permanentflags problem in the past, but bugs should have been fixed. Is the bug back or is there something wrong with my configuration? Best Regards Tommi P.S. Here is my dovecot configuration: # 2.2.5: /etc/dovecot/dovecot.conf # OS: Linux 3.10.5-1-ARCH x86_64 auth_debug = yes debug_log_path = /var/log/dovecot_debug.log info_log_path = /var/log/dovecot.log mail_debug = yes mail_full_filesystem_access = yes mail_location = maildir:~/Maildir namespace inbox { hidden = no inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = type = private } passdb { driver = pam } plugin { mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename } ssl_cert = </etc/ssl/certs/dovecot.pem ssl_key = </etc/ssl/private/dovecot.pem userdb { driver = passwd }

3 4

[Dovecot] force ciphers order for clients
by Robert Schetterer 14 Aug '13

14 Aug '13

Hi Timo, reading this http://www.kuketz-blog.de/perfect-forward-secrecy-mit-apple-mail/ it looks like DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA can be forced in use with apple mail ( if no ECDHE is possible ,by missing openssl 1.x etc, seems that apple mail tries ECDHE first if fails its going to use RSA-AES128-SHA ) force soltution as tried ssl_cipher_list = DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!PSK:!SRP:!DSS:!SSLv2:!RC4 so far so good , it worked nice with recent thunderbird too but it fails with outlook 2003 pop3s / win7 so i thought about using an order like this ssl_cipher_list = DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ALL:!LOW:!SSLv2:!EXP:!aNULL does that makes sense ? ( using dove 2.1.x / openssl 0.9x ) Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

3 7

Re: [Dovecot] force ciphers order for clients
by Reindl Harald 14 Aug '13

14 Aug '13

Am 14.08.2013 22:04, schrieb Robert Schetterer: > Am 14.08.2013 21:30, schrieb Reindl Harald: >> Am 14.08.2013 21:19, schrieb Robert Schetterer: >>>>> thx Harald, upgrading openssl to 1.x and using dove 2.2.5 is no option >>>>> at my setup lucid ubuntu yeter >>>> >>>> so you can practically forget it >>> >>> perhaps true forever, as long old clients are around, cause the server >>> can only workaround them >> >> not absolutely >> >> playing around with the setings below and https://www.ssllabs.com/ssltest/ >> turned out that the order is what counts, and that is really tricky >> >> i played around 5 hours with this absoluetly crap > > that sounds good, so you allready did many real world tests yeah and the bad is that it prove *currently* it is imposible to have perfect forward secrecy for most real world clients without open other vectors leading to fall back to a yellow B really sad is that playing around turned out how hard it is to force different clients at the same time to a good cipher and how one change in the order refelcts the overall result and facing this: "ssllabs" simulates negotiation of real clients (skipped in the screenshot) but we are missing the same for mailservers and thats why my conclusion is that we are hopeless as admins and can only offer things but not do much in case of clients using them __________________________ attached the current results for our webservers the only positive from the current resullt is that the sever supports ciphers for "Perfect Forward Secrecy" and the negative that it is only theory, so i stay at this config and say "dear browser vendors, i support it so use it with your damned client" because i can hardly use a config which get a yellow CVSS on security-audits to support FS for you" well, i could reven aise up "key exchange" to 90/95 but after that "FS" would not be listed at all the real sad thing is that the "FS" you see is not used by current clients which mostly use RC4 and if you add !MEDIUM the most start using FS-ciphers but are vulerable by BEAST-attack which let you fall down to grade B if i add !MEDIUM to dovecot Thunderbird does no longer connect at all

1 1

[Dovecot] weird situation with pop3/imap proxy and postfix authentication
by Leonardo Rodrigues 14 Aug '13

14 Aug '13

Hello dovecot mailing list, I have a server running postfix and dovecot. I havea configuration on dovecot that allows me to provide imap4/pop3 messages for local hosted users as well as for proxied users on other servers. Basically, i have a simple MySQL table (imapproxy) with two fields, 'domain' and 'host'. My password_query isa 'UNION' query, exactly like: password_query=select endereco as user, password, '/var/spool/mail/%u' as userdb_home, 'maildir:/var/spool/mail/%u' as userdb_mail, 8 as userdb_uid, 12 as userdb_gid, concat('*:storage=', quota) as userdb_quota_rule, 'Trash:storage=+100M' as userdb_quota_rule2, 'Y' as proxy_maybe, '10.252.38.2' as host from emails where endereco = '%u' and ativa = '1' UNION select NULL as user, '%w' as password, NULL as userdb_home, NULL as userdb_mail, NULL as userdb_uid, NULL as userdb_gid, NULL as userdb_quota_rule, NULL as userdb_quota_rule2, 'Y' as proxy_maybe, imapproxy.host as host from imapproxy where imapproxy.dominio = '%d' the 10.252.38.2 address, on the query, is my local server when this query received a local user, from a domain that is NOT listed on the imapproxy table, results are like: *************************** 1. row *************************** user: localuser(a)domain.com.br password: (SSHA256 encrypted password) userdb_home: /var/spool/mail/localuser(a)domain.com.br userdb_mail: maildir:/var/spool/mail/localuser@domain.com.br userdb_uid: 8 userdb_gid: 12 userdb_quota_rule: *:storage=51200 userdb_quota_rule2: Trash:storage=+100M proxy_maybe: Y host: 10.252.38.2 when it receives a proxied domain, results are: *************************** 1. row *************************** user: NULL password: password userdb_home: NULL userdb_mail: NULL userdb_uid: NULL userdb_gid: NULL userdb_quota_rule: NULL userdb_quota_rule2: NULL proxy_maybe: Y host: 10.254.116.9 This is working just fine for IMAP4 and POP3 proxying. Local users (which domains are NOT listed on imapproxy table) can successfully login to their accountsas well as users from domains listed on imapproxy table can successfully login to their accounts. On SMTP authentication, tough, things are not so fine. SMTP authentication is provided by dovecot to postfix: [root@correio dovecot]# postconf mail_version mail_version = 2.7.1 [root@correio dovecot]# smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = /var/spool/postfix/private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_type = dovecot service auth is defined on dovecot confs as: service auth { unix_listener auth-userdb { mode = 0600 user = mail group = mail } # Postfix smtp-auth unix_listener /var/spool/postfix/private/auth { mode = 0660 user = postfix group = postfix } } and it seems to be allowing ANYuser on any domain listed on the imapproxy table domains to login, even if the user does not exists or provides wrong password. In fact, it seems dovecot returns OK to postfix even without trying to contact the assigned server to that domain, as i cannot find any password-failed-specific log to that user on the specific server. Example: (a proxied domain) [root@correio dovecot]# telnet mail.proxieddomain.com.br 110 Trying 10.254.116.9... Connected to mail.proxieddomain.com.br (10.254.116.9). Escape character is '^]'. +OK Dovecot ready. user teste(a)proxieddomain.com.br +OK pass password -ERR Authentication failed. (i can successfully find this auth trial and fail on 10.254.116.9 logs) but on SMTP authentication, i have: [root@correio dovecot]# perl -MMIME::Base64 -e \ 'print encode_base64("teste\@proxieddomain.com.br\0teste\@proxieddomain.com.br\0password");' xxxxxxxxx(not the real encoded pass)xxxxxxxxxxxxxxxx= [root@correio dovecot]# [root@correio dovecot]# telnet localhost 587 Trying 127.0.0.1... Connected to localhost.localdomain (127.0.0.1). Escape character is '^]'. 220 mail.domain.com.br ESMTP EHLO test 250-mail.domain.com.br [ ... ] AUTH PLAIN (encoded string returned by perl encode_base64) 235 2.7.0 Authentication successful (and i cannot even find any authentication log, fail or success, on the specific server for proxieddomain.com.br) dovecot version is: [root@correio dovecot]# dovecot --version 2.2.2 [root@correio dovecot]# what am i doing wrong here ? How to have dovecot to really check users before giving OK to postfix on SMTP authentications ? Thanks for any hints ! -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertrudes(a)solutti.com.br My SPAMTRAP, do not email it

1 0

[Dovecot] Patch to log the cipher suite used for TLS
by Matthias Scheler 14 Aug '13

14 Aug '13

Hello, the attached patch for Dovecot 2.2.4 improves the logging to include information about the cipher suite used for a TLS connection. Here is an example log line: Aug 13 21:49:55 colwyn dovecot: imap-login: Login: user=<tron>, method=CRAM-MD5, rip=2001:8b0:114:1::2, lip=2001:8b0:114:1::2, mpid=10567, TLS=<TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)>, session=<ZkEhYtrjSgAgAQiwARQAAQAAAAAAAAAC> This will e.g. allow you to find out that mobile phones use rather week cipher suites (128bit keys, no PFS). There is also something else I noticed. If I switch "mutt" (which generated the above log line) from using IMAP on port 143 and "STARTTLS" to use IMAPS on port 993 I get TLS 1.2: Aug 14 07:44:59 colwyn dovecot: imap-login: Login: user=<tron>, method=CRAM-MD5, rip=2001:8b0:114:1::2, lip=2001:8b0:114:1::2, mpid=1156, TLS=<TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)>, session=<0js/suLj9gAgAQiwARQAAQAAAAAAAAAC> Not sure why TLS 1.2 is only used in this case. It might be "mutt" doing that. Kind regards -- Matthias Scheler http://zhadum.org.uk/

2 2

[Dovecot] SA54438
by Timo Sirainen 14 Aug '13

14 Aug '13

http://secunia.com/advisories/54438/ Since I already got 3 private mails about this, here's the same reply for everyone (actually updated, now that I looked at the code): This was a v2.2-only bug. And it isn't really a DoS.. It only caused the one pop3 process to crash in assert, which was handling only the connection that had already disconnected. (Unless you were running a non-recommended configuration with multiple clients per process.) So the only problem it caused was that Dovecot logged an assert error and maybe wrote a core dump.

3 2

[Dovecot] Dovecot security
by Jay Khashan 14 Aug '13

14 Aug '13

Hi, THIS IS URGENT I have Debian Linux machine which I installed as a mail server with postfix, and dovecot. my mail server is setup to use SMTP relay. I currently have ports 143, 995, 25 & SSMTP ports open. in the last few days I have been under attack where email is being sent to fake email address for example xxx(a)evg-mail.org which does not exist in the mysql db. I need to figure out and lock down dovecot, because I believe the attack is some kind of virus /spyware. I need to know what statement in dovecot.conf or main.cf (postfix) I can modify to lock it down. Also open to install software to combat this kind of attack. Let me know what configuration files, info do you need to help out Many Thanks ~Jay

4 3

[Dovecot] HG changes affecting received headers
by Thomas Leuxner 13 Aug '13

13 Aug '13

Let me say this is a rather cosmetic issue, but it appears with the latest commits (around 2.2.5 release) the scheme of 'Received' headers has changed for LMTP: 1) Inet socket: Return-Path: <dfn-adv-bounces(a)dfn-cert.de> Delivered-To: <tlx(a)leuxner.net> Received: from spectre.leuxner.net ([188.138.0.199]) by spectre.leuxner.net (Dovecot) with LMTP id 8AkXDF5cA1LvDgAAZ53dLw for <tlx(a)leuxner.net>; Thu, 08 Aug 2013 10:52:46 +0200 2) UNIX socket: Return-Path: <dfn-adv-bounces(a)dfn-cert.de> Delivered-To: <tlx(a)leuxner.net> Received: from spectre.leuxner.net ([]) by spectre.leuxner.net (Dovecot) with LMTP id q8WuGflcA1I3DwAAZ53dLw for <tlx(a)leuxner.net>; Thu, 08 Aug 2013 10:55:21 +0200 3) Old (Pre 2.2.5) build, UNIX socket: Return-Path: <dfn-adv-bounces(a)dfn-cert.de> Delivered-To: <tlx(a)leuxner.net> Received: from spectre.leuxner.net by spectre.leuxner.net (Dovecot) with LMTP id 8NiKKX0h+lFRIAAAZ53dLw for <tlx(a)leuxner.net>; Thu, 01 Aug 2013 10:51:09 +0200 While it probably should resolve the FQDN in 1) (Postfix does), not sure what it should do with a UNIX socket in 2). Previously as shown in 3) it had none of it... Thomas

2 5