- dovecot - dovecot.org

acl_groups in LDAP
by Christian Rößner 06 Feb '19

06 Feb '19

Hi, I found a 9 year old thread (https://www.dovecot.org/list/dovecot/2010-October/054407.html) concerning acl_groups in OpenLDAP. In this thread someone asked, if it is possible to provide ACLs as multi value in OpenLDAP. I know that Dovecot expects acl_groups as a comma separated list, so currently I do this with a single value. Did the code change a little bit and accepts multi values now? Would be nice to have attributes like: ACLAttribute: group1 ACLAttribute: group2 ... Instead of: ACLAttribute: group1,group2 Thanks in advance Christian -- Rößner-Network-Solutions Karl-Bröger-Str. 10, 36304 Alsfeld T: +49 6631 9110725, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner-network-solutions.com

2 1

Release notify (2.2.36.1 and 2.3.4.1)
by Aki Tuomi 06 Feb '19

06 Feb '19

Due to DMARC issues some people have failed to receive the latest security information, so here it is repeated for both releases: 2.3.4.1 https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig <https://dovecot.org/releases/2.3/dovecot-2.3.2.tar.gz.sig> Binary packages in https://repo.dovecot.org/ * CVE-2019-3814: If imap/pop3/managesieve/submission client has trusted certificate with missing username field (ssl_cert_username_field), under some configurations Dovecot mistakenly trusts the username provided via authentication instead of failing. * ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This bug didn't affect Dovecot's Submission service. 2.2.36.1 https://dovecot.org/releases/2.2/dovecot-2.2.36.1.tar.gz https://dovecot.org/releases/2.2/dovecot-2.2.36.1.tar.gz.sig * CVE-2019-3814: If imap/pop3/managesieve/submission client has trusted certificate with missing username field (ssl_cert_username_field), under some configurations Dovecot mistakenly trusts the username provided via authentication instead of failing. * ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This bug didn't affect Dovecot's Submission service. - pop3_no_flag_updates=no: Don't expunge RETRed messages without QUIT - director: Kicking a user assert-crashes if login process is very slow - lda/lmtp: Fix assert-crash with some Sieve scripts when mail_attachment_detection_options=add-flags-on-save - fs-compress: Using maybe-gz assert-crashed when reading 0 sized file - Snippet generation crashed with invalid Content-Type:multipart

4 13

SELinux policy to allow Dovecot to connect to Mysql
by Robert Moskowitz 06 Feb '19

06 Feb '19

As I have noted in previous messages, I been getting the following on my new mailserver: Apr 7 10:17:27 z9m9z dovecot: dict: Error: mysql(localhost): Connect failed to database (postfix): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (13) - waiting for 25 seconds before retry They go away when I setenforce 0. It is not a timing issue as I earlier thought. So I googled dovecot mysql selinux and the only worthwhile hit was: http://zszsit.blogspot.com/2012/12/dovecot-mysql-selinux-issue-on-centos6.h… that provides a /etc/selinux/dovecot2mysql.te and other selinux stuff. Is there a simpler way like a setsbool option? With all the howtos on dovecot with mysql, it is interesting that none of them seem to have this problem. Maybe because they connect to mysql through TCP port 3306 which has ITS set of problems (like MariaDB defaults to not listening on TCP). thanks!

1 3

problem using different dovecot versions
by Gonzalo Palacios Goicolea 05 Feb '19

05 Feb '19

Hi All, I'm new to the list and may be it's a known issue. I have a set of servers with RHEL6 and dovecot-2.2.10-1_14.el6.x86_64 and another set of servers with RHEL7 and, now, with dovecot-2.2.36-3.el7.x86_64. Both sets write to the same NFS. Since I updated RHEL7 servers (from 2.2.10-8.el7.x86_64) I've problems with index files when a RHEL7 dovecot service write to the filesystem of a user (the first log line corresponds to RHEL7 and the others to RHEL6): Feb 5 09:33:05 listas3 dovecot: lda(user@domain): sieve: msgid=<007bxxxxxxx(a)uam.es>: stored mail into mailbox 'INBOX' Feb 5 09:33:25 buzon1 dovecot: imap(user@domain): Error: Corrupted transaction log file /.../Maildir/dovecot.index.log seq 1610: Invalid transaction log size (28408 vs 28528): /.../Maildir/dovecot.index.log (sync_offset=28408) Feb 5 09:33:25 buzon1 dovecot: imap(user@domain): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record)) Feb 5 09:33:25 buzon1 dovecot: imap(user@domain): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0() [0x3713268b8a] -> /usr/lib64/dovecot/libdovecot.so.0() [0x3713268bf6] -> /usr/lib64/dovecot/libdovecot.so.0() [0x37132224aa] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_sync_keywords+0x7fd) [0x3713aca43d] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_sync_record+0xec) [0x3713acacac] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_sync_map+0x234) [0x3713acbae4] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_map+0x83) [0x3713abcce3] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_refresh+0xe) [0x3713ab793e] -> /usr/lib64/dovecot/libdovecot-storage.so.0(maildir_sync_header_refresh+0x10) [0x3713a4e1e0] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3713a4e330] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3713a4f3d4] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3713a4f7b3] -> /usr/lib64/dovecot/libdovecot-storage.so.0(maildir_storage_sync_init+0xd9) [0x3713a4fa59] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_sync_init+0x31) [0x3713a7d731] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_sync+0x27) [0x3713a7e7b7] -> /usr/lib64/dovecot/libdovecot-storage.so.0(index_storage_get_status+0x62) [0x3713aa8fc2] -> /usr/lib64/dovecot/lib10_quota_plugin.so(+0xc3ec) [0x7fd272dfe3ec] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_get_status+0x5c) [0x3713a7f4fc] -> dovecot/imap(imap_status_get+0x7a) [0x41dbea] -> dovecot/imap(cmd_status+0x179) [0x413059] -> dovecot/imap(command_exec+0x3d) [0x4170bd] -> dovecot/imap() [0x416180] -> dovecot/imap() [0x41627a] -> dovecot/imap(client_handle_input+0x11d) [0x4164ed] -> dovecot/imap(client_input+0x6f) [0x41685f] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x36) [0x3713278a56] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0xa7) [0x3713279b27] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x37132789c8] Feb 5 09:33:25 buzon1 dovecot: imap(user@domain): Fatal: master: service(imap): child 2057 killed with signal 6 (core dumped) Feb 5 09:33:25 buzon4 dovecot: imap-login: Login: user=<user@domain>, method=PLAIN, rip=192.168.x.x, lip=150.x.x.x, mpid=3459, session=<ZUSAdiGBdwDAqAzY> Feb 5 09:33:30 buzon4 dovecot: imap(user@domain): Panic: file mail-index-sync-keywords.c: line 227 (keywords_update_records): assertion failed: (data_offset >= sizeof(struct mail_index_record)) Feb 5 09:33:30 buzon4 dovecot: imap(user@domain): Error: Raw backtrace: /usr/lib64/dovecot/libdovecot.so.0() [0x3a88668b8a] -> /usr/lib64/dovecot/libdovecot.so.0() [0x3a88668bf6] -> /usr/lib64/dovecot/libdovecot.so.0() [0x3a886224aa] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_sync_keywords+0x7fd) [0x3a88eca43d] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_sync_record+0xec) [0x3a88ecacac] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_sync_map+0x234) [0x3a88ecbae4] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_map+0x83) [0x3a88ebcce3] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3a88eb797c] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3a88eb7d58] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mail_index_open+0xf0) [0x3a88eb7ec0] -> /usr/lib64/dovecot/libdovecot-storage.so.0(index_storage_mailbox_open+0xad) [0x3a88eab2bd] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3a88e4d71a] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3a88e4d7ef] -> /usr/lib64/dovecot/libdovecot-storage.so.0() [0x3a88e7f694] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_open+0xf) [0x3a88e7f84f] -> /usr/lib64/dovecot/libdovecot-storage.so.0(index_storage_get_status+0x4a) [0x3a88ea8faa] -> /usr/lib64/dovecot/lib10_quota_plugin.so(+0xc3ec) [0x7fbd599263ec] -> /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_get_status+0x5c) [0x3a88e7f4fc] -> dovecot/imap(imap_status_get+0x7a) [0x41dbea] -> dovecot/imap(cmd_status+0x179) [0x413059] -> dovecot/imap(command_exec+0x3d) [0x4170bd] -> dovecot/imap() [0x416180] -> dovecot/imap() [0x41627a] -> dovecot/imap(client_handle_input+0x11d) [0x4164ed] -> dovecot/imap(client_input+0x6f) [0x41685f] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x36) [0x3a88678a56] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0xa7) [0x3a88679b27] -> /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x3a886789c8] Feb 5 09:33:30 buzon4 dovecot: imap(user@domain): Fatal: master: service(imap): child 3459 killed with signal 6 (core dumped) Due to this issue when the user goes into his webmail, he can not see the inbox. If I delete dovecot.* files from the user maildir it gets solved, but usually it happens again, so it's not the solution. Is it any solution for this issue or should I downgrade dovecot to 2.2.10-8.el7.x86_64 again? Thanks and best regards -- *Gonzalo Palacios Goicolea* U.T de Infraestructura de Equipos Centrales /Tecnologías de la Información/ Universidad Autónoma de Madrid • Campus de Cantoblanco <3D"http://www.uam.es/">

1 0

CVE-2019-3814: Suitable client certificate can be used to login as other user
by Aki Tuomi 05 Feb '19

05 Feb '19

Dear subscribers, we're sharing our latest advisory with you and would like to thank everyone who contributed in finding and solving those vulnerabilities. Feel free to join our bug bounty programs (open-xchange, dovecot, powerdns) at HackerOne. Please find patches for v2.2.36 and v2.3.4 attached, or download new version from https://dovecot.org Yours sincerely, Aki Tuomi Open-Xchange Oy Product: Dovecot Vendor: Open-Xchange Oy Internal reference: DOV-2890 (Bug ID) Vulnerability type: Improper Authentication - Generic (CWE287) Vulnerable versions: 1.1.0 - 2.2.36 and 2.3.0 - 2.3.4 Vulnerable component: authentication Report confidence: Confirmed Solution status: Fixed by Vendor Fixed versions: 2.2.36.1, 2.3.4.1 Vendor notification: 2019-01-16 Solution date: 2019-01-20 Public disclosure: 2019-02-05 Researcher Credits: https://hackerone.com/halfdog CVE reference: CVE-2019-3814 CVSS: 8.2 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N) Vulnerability Details: Normally Dovecot is configured to authenticate imap/pop3/managesieve/submission clients using regular username/password combination. Some installations have also required clients to present a trusted SSL certificate on top of that. It's also possible to configure Dovecot to take the username from the certificate instead of from the user provided authentication. It's also possible to avoid having a password at all, only trusting the SSL certificate. If the provided trusted SSL certificate is missing the username field, Dovecot should be failing the authentication. However, the earlier versions will take the username from the user provided authentication fields (e.g. LOGIN command). If there is no additional password verification, this allows the attacker to login as anyone else in the system. This affects only installations using: auth_ssl_require_client_cert = yes auth_ssl_username_from_cert = yes Attacker must also have access to a valid trusted certificate without the ssl_cert_username_field in it. The default is commonName, which almost certainly exists in all certificates. This could happen for example if ssl_cert_username_field is a field that normally doesn't exist, and attacker has access to a web server's certificate (and key), which is signed with the same CA. Attack can be migitated by having the certificates with proper Extended Key Usage, such as 'TLS Web Server' and 'TLS Web Server Client'. Also, ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This does not apply to Dovecot Submission service. Proof of concept Create a CA certificate for signing, and sign a certificate with missing commoName attribute. With following configuration passdb { driver = static arguments = nopassword } ssl_ca =</path/to/ca.pem auth_ssl_require_client_cert = yes auth_ssl_username_from_cert = yes You are able to log in as any user with this certificate using following commands: openssl s_client -connect server:port -cert /path/to/cert -key /path/to/key a LOGIN anyusername anypassword

1 0

Dovecot 2.3.4.1 released
by Aki Tuomi 05 Feb '19

05 Feb '19

https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.4.1.tar.gz.sig <https://dovecot.org/releases/2.3/dovecot-2.3.2.tar.gz.sig> Binary packages in https://repo.dovecot.org/ * CVE-2019-3814: If imap/pop3/managesieve/submission client has trusted certificate with missing username field (ssl_cert_username_field), under some configurations Dovecot mistakenly trusts the username provided via authentication instead of failing. * ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This bug didn't affect Dovecot's Submission service. --- Aki Tuomi Open-Xchange oy

1 0

acl_groups from LDAP issue
by Jakobus Schürz 04 Feb '19

04 Feb '19

Hi! I have some trouble with userdb, ldap an extrafields for acl_groups. There is a script in python, which fetches the groups and sets the environment-variable ACL_GROUPS to this groups. It works when i log in to imap (thunderbird for example shows my public folders which are protected by acl_groups). But when it try doveadm mailbox list -u user.name the mailboxes are not listed and with -Dv i get "permission denied, no lookup rights". in my dovecot-ldap-userdb.conf.ext is hosts = ldap.server.example dn = cn=service_id,ou=mailserver,ou=system,ou=services,dc=server,dc=example dnpass = protectedpassword12345 tls = yes tls_ca_cert_file = /etc/ssl/certs/ca-certificates.crt tls_require_cert = demand ldap_version = 3 base = ou=users,dc=server,dc=example deref = always scope = subtree user_attrs = =home={ldap:dcMailMessageStore},system_groups_user=%u,allow_all_users=yes,=acl_groups=%{env:ACL_GROUPS} user_filter = (&(objectClass=posixAccount)(uid=%u)(!(sn=NoLogin))(|(memberof=cn=perm-app-mymail_admins,ou=mymail,ou=apps,ou=services,dc=schuerz,dc=at)(memberof=cn=perm-app-mymail_users,ou=mymail,ou=apps,ou=services,dc=schuerz,dc=at))) when i change acl_groups=%{env:ACL_GROUPS} to acl_gropus=mygroup, the doveadm mailbox list command shows my public mailbox So how do i get my acl_groups from the postlogin-script output into userdb-query? Even, when i do on the shell ACL_GROUPS=mygroup doveadm mailbox list -u user.name the ACL_GROUPS Environment is ignored by the doveadm-command... thank you jakob

2 2

Issues with stats-writer
by Remo Mattei 04 Feb '19

04 Feb '19

Here is the full mail coming in: @400000005c57633625970624 starting delivery 12824: msg 1270896 to local ma.org-you(a)mattei.org <mailto:ma.org-you@mattei.org> @400000005c57633625970a0c status: local 1/10 remote 0/60 @400000005c57633711a138c4 delivery 12824: success: lda(you(a)ma.org <mailto:you@ma.org>,)Error:_net_connect_unix(/var/run/dovecot/stats-writer)_failed:_Permission_denied/did_0+0+1/ @400000005c57633711a1447c status: local 0/10 remote 0/60 I am using qmail for some reasons I have the error above. I have tried the following: #service stats { # unix_listener stats-reader { # user = root # group = dovecot # mode = 0660 # } # # unix_listener stats-writer { # user = root # group = dovecot # mode = 0660 # } #} But still no luck still have the same issue. Any tips are welcomed. Remo

1 0

Multi-dbox storage space
by MRob 04 Feb '19

04 Feb '19

Hi, I originally picked mdbox because I had the impression from reading about it on the mailing list that it was more performant and that it would conserve disc space. But lately i found mailboxes have nearly double the storage as reported. I mean, IMAP QUOTA reports around 900MB for one account that has over 2GB when I inspect the mail location of the user using the linux command `du` Another account has around 750MB according to IMAP but using du I find 1.5GB. This is for message files and index files combined. Is this normal? I tried to read the MailboxFormat/dbox wiki page and it does not directly address this topic but it does reference "doveadm purge". Do I need to use "doveadm purge"?

2 2

Crash when using dict quotas with sqlite database
by Marcel Menzel 04 Feb '19

04 Feb '19

Hello, After I configured a SQLite backed dict quota backend, the dict process crashes every time a quota operation is happening. SQLite: 3.26.0 Dovecot: 2.3.4 (0ecbaf23d) Linux: 4.20.4.a-1-hardened #1 SMP PREEMPT Fri Jan 25 01:24:51 CET 2019 x86_64 GNU/Linux (Arch Linux) Filesystem: BTRFS I can't get any debug output from Dovecot, even after setting log_debug = cat:* event:* source:* field:*=* dovecot[6457]: dict(6687): Debug: sqlite: Finished query 'BEGIN TRANSACTION' in 0 msecs dovecot[6457]: dict(6687): Fatal: master: service(dict): child 6687 killed with signal 11 (core dumped) I've attached the output of dovecot -n and the coredump file from systemd-coredump. Kind regards, Marcel Menzel

3 12