October 2023 - dovecot

{ldap:objectGUID} returns binary data when used for user_attrs
by Andreas Haerter 26 Oct '23

26 Oct '23

Hi, there is an environment in which I have to use MS Active Directory for authentication and mail server user database, and I've run into a problem. I. The problem I want to retrieve the objectGUID attribute for the homedir path of the users. This attribute does never change, even when the username does or the account gets moved to another AD domain. However, the objectGUID is returned as binary gibberish when using the following setting: > user_attrs = \ > =home=/var/vmail/example.com/%LT{ldap:objectGUID}, \ It results in > # doveadm user uTesting > field value > user utesting > home /var/vmail/example.com/d ��n�aa_ o�� > mail maildir:~/mail Can someone reproduce this or offer a workaround? The only idea I had was hashing the value using =%M{ldap:objectGUID}. However, this approach would become problematic if the behavior changes and a proper string representation is returned, as expected, instead of the binary data. Therefore, I'm hesitant to use this method for now. A better approach would be encoding it as Base64, but I was unsuccessful to identify a fitting modifier at <https://doc.dovecot.org/configuration_manual/config_file/config_variables/#…>. Any ideas? II. Additional info Using other attributes for LDAP/Active Directory works as expected. E.g. > =home=/var/vmail/example.com/%LT{ldap:sAMAccountName} results in > # doveadm user uTesting > field value > user utesting > home /var/vmail/example.com/utesting > mail maildir:~/mail The objectGUID is indeed binary data, but IHMO, it should be handled differently when returned. E.g. there is a defined string representation, [MS-DTYP] section 2.3.4.3: <https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/222af…> which links to: > curly braced GUID string: The string representation of a 128-bit > globally unique identifier (GUID) using the form > {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}, where X denotes a hexadecimal > digit. The string representation between the enclosing braces is the > standard representation of a GUID as described in [RFC4122] section 3. > Unlike a GUIDString, a curly braced GUID string includes enclosing braces. Some libs simply decide to return the data Base64 encoded (which would be OK, too). E.g. openldap-clients / ldapsearch does so with objectGUID and objectSid: > $ ldapsearch [...] > [...] > # uTesting, common, user, managed, example.com > dn: CN=uTesting,OU=common,OU=user,OU=managed,DC=example,DC=com > [...] > name: uTesting > objectGUID:: RCDirQPvGU6KQUFfIE/i2Q== > [...] > objectSid:: AQUAAAAAAAUVAAAALenCqsullBUfFoubWQQAAA== > [...] > sAMAccountName: uTesting > [...] Other software had comparable bugs or behavior , e.g. sssd ("Properly handle AD's binary objectGUID"): <https://bugzilla.redhat.com/show_bug.cgi?id=1205382> <https://github.com/SSSD/sssd/issues/3629> owncloud ("ensure that objectguid or guid really return binary data before converting it"): <https://github.com/owncloud/core/issues/8317> III. Software versions, config I can reproduce the issue on Fedora Server 38 > # cat /etc/redhat-release > Fedora release 38 (Thirty Eight) > # uname -r > 6.4.15-200.fc38.x86_64 > # dovecot --version > 2.3.20 (80a5ac675d) and CentOS 9 Stream: > # cat /etc/redhat-release > CentOS Stream release 9 > # uname -r > 5.14.0-364.el9.x86_64 > # dovecot --version > 2.3.16 (7e2e900c1a) I did not try a Debian-based distro yet. The config itself works fine, relevant settings just for reference (as there are not many examples on the internet, maybe useful for somebody): > auth_username_format = %Lu > > passdb { > driver = ldap > args = /etc/dovecot/dovecot-ldap.conf.ext > } > userdb { > driver = ldap > args = /etc/dovecot/dovecot-ldap-userdb.conf.ext > } with the following options to exclude inactive accounts, search smtp proxy addresses and having a mandatory group membership in SERVICE_EmailUsers: > base = OU=common,OU=user,OU=managed,DC=example,DC=com > scope = subtree > > user_filter = \ > (& \ > (objectClass=user) \ > (objectCategory=Person) \ > (|(sAMAccountName=%{username})(mail=%{username})(proxyAddresses=smtp:%{username}@%{domain})) \ > (!(userAccountControl:1.2.840.113556.1.4.803:=2)) \ > (memberOf:1.2.840.113556.1.4.1941:=SERVICE_EmailUsers) \ > ) > pass_filter = \ > (& \ > (objectClass=user) \ > (objectCategory=Person) \ > (|(sAMAccountName=%{username})(mail=%{username})(proxyAddresses=smtp:%{username}@%{domain})) \ > (!(userAccountControl:1.2.840.113556.1.4.803:=2)) \ > (memberOf:1.2.840.113556.1.4.1941:=SERVICE_EmailUsers) \ > ) I will blog about the config in more detail at https://foundata.com/en/blog/ soon, especially when the objectGUID is solved (maybe hashing it really the way to go). :-) Regards, Andreas -- foundata GmbH Steinhäuserstr. 20 76135 Karlsruhe Sitz der Gesellschaft: Karlsruhe Registergericht: Amtsgericht Mannheim, HRB 714807 Geschäftsführer: Andreas Haerter USt-IdNr.: DE284122682

1 1

Correct sizing of CPU and RAM
by DeJa Wu 26 Oct '23

26 Oct '23

How to correctly calculate the number of CPUs and memory required for 1000 client mailboxes and beyond? Given that 30-50% of users will be constantly connected via IMAP. I looked for information and did not find any sizing in the documentation anywhere. Is there a way to calculate my required resources? BR, DeJa How to correctly calculate the number of CPUs and memory required for 1000 client mailboxes and beyond? Given that 30-50% of users will be constantly connected via IMAP. I looked for information and did not find any sizing in the documentation anywhere. Is there a way to calculate my required resources? BR, DeJa

2 1

OAUTH2 tokeninfo is doing a GET instead of a POST request
by Alexander Leidinger 26 Oct '23

26 Oct '23

Hi, I try to setup oauth2 authentication with dovecot 2.3.21. The debug log of dovecot shows that it tries to do a HTTP GET request to the tokeninfo url with the token appended to the end of the URL. This gives a 404 error. The openidconnect server I use (keycloak) tells that this API endpoint conforms to https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint which specifies that the request has to be a HTTP POST request. So dovecot is trying do to something (GET request) which the OIDC specification does not agree with (shall be POST request). Here is the dovecot debug log of it: ---snip--- Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: http-client[1]: request [Req1: GET https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/tokeneyJhb…<rest_omitted>...: Submitted (requests left=1) [...] Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld: SSL: where=0x1001, ret=1: SSLv3/TLS read server session ticket Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld: where=0x1002, ret=1: SSL negotiation finished successfully Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld: SSL: where=0x1001, ret=1: SSL negotiation finished successfully Oct 17 12:11:19 imap syslogd: last message repeated 1 times Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld: SSL: where=0x1001, ret=1: SSLv3/TLS read server session ticket Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: oauth2.domain.tld: SSL: where=0x1002, ret=1: SSL negotiation finished successfully Oct 17 12:11:19 imap dovecot[81589]: auth: Debug: http-client: conn <IP>:443 [1]: Got 404 response for request [Req1: GET https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/tokeneyJhb…<rest_omitted> ---snip--- My passdb config (only showing the oauth part): ---snip--- passdb { driver = oauth2 mechanisms = oauthbearer xoauth2 args = /usr/local/etc/dovecot/auth-oauth2.token.conf.ext } passdb { driver = oauth2 mechanisms = plain args = /usr/local/etc/dovecot/auth-oauth2.plain.conf.ext } ---snip--- auth-oauth2.token.conf.ext: ---snip--- openid_configuration_url = https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration tokeninfo_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token introspection_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/intr… introspection_mode = post active_attribute = active active_value = true client_id = myid client_secret = mysecret use_grant_password = no debug = yes username_attribute = email pass_attrs = pass=%{oauth2:access_token} ---snip--- auth-oauth2.plain.conf.ext: ---snip--- openid_configuration_url = https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration #tokeninfo_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token introspection_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/intr… introspection_mode = post active_attribute = active active_value = true client_id = myid client_secret = mysecret use_grant_password = yes debug = yes username_attribute = email pass_attrs = host=<IP of webmail> proxy=y proxy_mech=xoauth2 pass=%{oauth2:access_token} ---snip--- On https://doc.dovecot.org/configuration_manual/authentication/oauth2/ I can not find any way to tell that the tokeninfo url shall do a POST request instead of a GET request. I found something on reddit how to make it work with keycloak, but this seems to be a workaround, and not a proper fix... The first comment at https://www.reddit.com/r/selfhosted/comments/omwb2j/any_one_get_dovecot_key… makes this work for me. The working but not really up to the OIDC spec dovecot config is: auth-oauth2.token.conf.ext: ---snip--- openid_configuration_url = https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration #tokeninfo_url = https://oauth2.domain.tld/realms/MyRealm/Leidinger/protocol/openid-connect/… tokeninfo_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/userinfo?t… introspection_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/intr… introspection_mode = auth #active_attribute = active #active_value = true client_id = myid client_secret = mysecret use_grant_password = no #debug = yes username_attribute = email pass_attrs = pass=%{oauth2:access_token} ---snip--- auth-oauth2.plain.conf.ext: ---snip--- openid_configuration_url = https://oauth2.domain.tld/realms/MyRealm/.well-known/openid-configuration #tokeninfo_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token tokeninfo_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/userinfo?t… introspection_url = https://oauth2.domain.tld/realms/MyRealm/protocol/openid-connect/token/intr… introspection_mode = auth #active_attribute = active #active_value = true client_id = myid client_secret = mysecret use_grant_password = yes #debug = yes username_attribute = email pass_attrs = host=<IP of webmail> proxy=y proxy_mech=xoauth2 pass=%{oauth2:access_token} ---snip--- Bye, Alexander. -- http://www.Leidinger.net Alexander(a)Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild(a)FreeBSD.org : PGP 0x8F31830F9F2772BF

2 8

Is it possible to show different mechanism according to client IP ?
by Philippe MARASSE 26 Oct '23

26 Oct '23

Hello, Say I'm wondering if it's possible to show 3 mechanisms for clients in private network (XOAUTH2 / PLAIN / EXTERNAL) and only 2 to others (only OAUTH / EXTERNAL) ? I've seen allow_nets extra field for args, but it seems that's not working with ldap passdb. Regards. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Cœur 86021 Poitiers Cedex Tel : 05.49.44.57.19 Hello, Say I'm wondering if it's possible to show 3 mechanisms for clients in private network (XOAUTH2 / PLAIN / EXTERNAL) and only 2 to others (only OAUTH / EXTERNAL) ? I've seen allow_nets extra field for args, but it seems that's not working with ldap passdb. Regards. -- Philippe MARASSE Responsable pôle Infrastructures - DSIO Centre Hospitalier Henri Laborit CS 10587 - 370 avenue Jacques Cœur 86021 Poitiers Cedex Tel : 05.49.44.57.19

2 1

Unclear output from force-resync.
by Justin Wheeler 25 Oct '23

25 Oct '23

Hi, After a hard drive issue from my VPS provider, one of my customers' mailboxes has been corrupted, and has been complaining about index sync issues. So I am attempting a force-resync. The command I used was: doveadm -v force-resync -u user(a)mailbox.com '*' The output it's been giving doesn't look anything like a 'progress counter', so I have no idea if it's just losing its mind, or if it's actually achieving anything. The mailbox is 20G, so theoretically it's just working its way through it, but I can't tell. The output looks like: doveadm(user(a)mailbox.com): Warning: fscking index file /home/mail/mailbox.com/user/mdbox/storage/dovecot.map.index doveadm(user(a)mailbox.com): Warning: mdbox /home/mail/mailbox.com/user/mdbox/storage: rebuilding indexes doveadm(user(a)mailbox.com): Warning: Transaction log file /home/mail/mailbox.com/user/mdbox/storage/dovecot.map.index.log was locked for 90 seconds (mdbox storage rebuild) doveadm(user(a)mailbox.com): Warning: fscking index file /home/mail/mailbox.com/user/mdbox/storage/dovecot.map.index doveadm(user(a)mailbox.com): Warning: fscking index file /home/mail/mailbox.com/user/mdbox/storage/dovecot.map.index doveadm(user(a)mailbox.com): Warning: mdbox /home/mail/mailbox.com/user/mdbox/storage: rebuilding indexes doveadm(user(a)mailbox.com): Warning: Transaction log file /home/mail/mailbox.com/user/mdbox/storage/dovecot.map.index.log was locked for 90 seconds (mdbox storage rebuild) It's just this over and over and over and over. Does this mean it's working, or that something else is going on? fuser /home/mail/mailbox.com/user/mdbox/storage/dovecot.map.index.log shows only the PID of the force-resync, and ls -l /proc/pid/fd shows it has a bunch of index and index.log and index.cache files open, as well as scrolling through mdbox/storage/m.{digits} a bunch, and strace -fp on the process shows a boatload of pread64 on those m.{digits} files, so I *think* it's working, but I can't tell if it's just restarting after the above messages and doing the same thing over and over again. I've locked the mailbox so there's no mail delivery being attempted on it, and changed its password and kicked out any logged in users on the mailbox, so the only process anywhere near that entire directory structure is the force-resync. Thanks, Justin

1 0

dovecot lmtp and smtputf8
by Kamil Jońca 25 Oct '23

25 Oct '23

Does dovecot handle smtputf8? Last articles regarding this are several years old. Anything changed? KJ

2 2

dovecot 2.0 supports EC private key?
by Marc 24 Oct '23

24 Oct '23

Does dovecot 2.0 supports EC private key?

2 1

Question: ETA OpenSSL 3.0 Support
by Niklas Meyer 23 Oct '23

23 Oct '23

Hello everyone, i stumbled across some serious problems with decrypting of e-mails if you use a Dovecot installation with OpenSSL 3.X so i started digging. It turns out that Dovecot is not OpenSSL 3.X ready yet, at least if you compile it yourself. The Debian Project adapted a OpenSSL 3.X patch to their repo version of Dovecot to make it run with Debian 12. Alpine Linux has not added a Workaround Patch for Dovecot yet. This is actually really bad if you want to Upgrade your Dovecot Server to a Distro which has OpenSSL 3.X as the new standard and you are not using their patched Repo Versions but instead compiling dovecot by yourself or install it from your package repos (which are not Debian 12 compatible also, which is probably because of OpenSSL 3.X i presume?) However though i think that this compatibility should be added soon as more and more Distros are using OpenSSL 3.X. So: Is there a approx. ETA when the OpenSSL Compatibility the devs worked/are working on is coming? Thank you for your answers. Kind regards from Germany Niklas Meyer aka. DerLinkman

2 3

Confusing documentation for 'address/listen' setting
by Bruno Victal 21 Oct '23

21 Oct '23

Hi, The 'address' setting in the “Service configuration” of the Configuration Manual [1] says: Space separated list of IP addresses / host names to listen on. […] Defaults to listen setting. I'm finding this part confusing as it seems that by “listen setting” it is referring to the 'listen' setting in the “Dovecot Core Manual” [2] which is described as: A comma-separated list of IP addresses or […] which leads me to suspect that either “listen setting” refers to something else (what?) or there's some inconsistency with the documentation or perhaps a bug/foot-gun here. [1]: <https://doc.dovecot.org/configuration_manual/service_configuration/#address> [2]: <https://doc.dovecot.org/settings/core/#core_setting-listen> Regards, -- Bruno.

1 0

Re: Dovecot behind Reverse Proxy and IP families
by Arnaud Cordier 20 Oct '23

20 Oct '23

On 10/13/23 06:55, Arnaud Cordier wrote: > Hi Justas, > > Thank you for your answer. Unfortunately, I already have a dual stack > cluster with an IPv6 assigned to the pod: > > 3: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1430 qdisc > noqueue state UP qlen 1000 > link/ether c6:90:d2:cf:b8:77 brd ff:ff:ff:ff:ff:ff > inet 10.42.4.52/32 scope global eth0 > valid_lft forever preferred_lft forever > inet6 fd23:23:42:0:251d:192a:bb7f:a1f4/128 scope global > valid_lft forever preferred_lft forever > inet6 fe80::c490:d2ff:fecf:b877/64 scope link > valid_lft forever preferred_lft forever > > Any additional idea? > > --- > Arnaud Cordier > --------------- > CryptID > Freelance cybersecurity engineer - Pentester - Red teamer > Tel: +33 (0)6 61 44 82 04 > On 10/12/23 22:54, Justas Umbrasas wrote: >> >> Hey, >> >> >> we are running a similar setup without an issue (not on k8s). I >> believe the reason is that the remote dovecot pod is only binding on >> IPv4 and has no IPv6 configured. This is kind of a hack, however you >> could try binding the pod to both IPv4 and IPv6 and see if it works. >> >> >> Best, >> >> Justas Umbrasas >> >> >> On 2023-10-12 20:25, Arnaud Cordier via dovecot wrote: >> >>> Dear all, >>> >>> I am running Dovecot 2.3.20 in a Kubernetes cluster. The Dovecot >>> container is exposed behind a Traefik load-balancer, which acts just >>> like HAProxy would, using the Proxy Protocol in order to allow >>> Dovecot to be aware of the real source IP of the client, as follows: >>> >>> Internet <-> Traefik load-balancer <---- Proxy protocol ----> Dovecot >>> >>> My setup works well over IPv4. >>> >>> Oct 12 19:11:33 imap-login: Info: Login: user=<arnaud@xxx>, >>> method=PLAIN, rip=<my_ipv4_public_address> lip=10.42.4.21, >>> mpid=1369531, session=<xxxx> >>> >>> Howevever, if the client originates from an IPv6 address, Dovecot >>> does not seem to take the real IPv6 origin into account and fails. >>> >>> Oct 12 19:09:04 imap-login: Error: haproxy(v1): Client disconnected: >>> Proxied local address is invalid (address=`10.42.4.21', rip=10.42.4.21) >>> >>> A network capture shows that the proxy protocol indeed sends the >>> real IPv6 IP, that should be taken into account by dovecot: >>> >>> ......&.PROXY TCP6 2001:<rest_of_my_public_ip> 10.42.4.21 20200 993 >>> >>> The error seems to be raised in >>> "core/src/lib-master/master-service-haproxy.c" line 553: >>> >>> 551 if (net_addr2ip(*fields, &local_ip) < 0 || >>> 552 local_ip.family != family) { >>> 553 e_error(hpconn->event, "Client disconnected: " >>> 554 "Proxied local address >>> is invalid " >>> 555 "(address=`%s', >>> rip=%s)", str_sanitize(*fields, 64), >>> 556 net_ip2addr(real_remote_ip)); >>> 557 return -1; >>> 558 } >>> 559 fields++; >>> >>> I suppose that the issue is related to the fact that the client >>> originates from an IPv6 then the reverse proxy forwards the >>> connection to Dovecot over IPv4, which results in the >>> "local_ip.family != family" condition to be true. >>> >>> Why is such a restriction implemented ? >>> >>> It is to be noted that I implemented the exact same load-balancer >>> architecture for postfix, which successfully handles an IPv6 real IP >>> over an IPv4 connection. >>> >>> I temporarily fixed the issue by setting an IPv4 only DNS record for >>> my imaps domain name, however, do you think that a fix could be >>> implemented in Dovecot? >>> >>> Kind regards, >>> >>> _______________________________________________ >>> dovecot mailing list -- dovecot(a)dovecot.org >>> To unsubscribe send an email to dovecot-leave(a)dovecot.org >> >> On 10/13/23 06:55, Arnaud Cordier wrote: Hi Justas, Thank you for your answer. Unfortunately, I already have a dual stack cluster with an IPv6 assigned to the pod: 3: eth0@if22: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1430 qdisc noqueue state UP qlen 1000 link/ether c6:90:d2:cf:b8:77 brd ff:ff:ff:ff:ff:ff inet 10.42.4.52/32 scope global eth0 valid_lft forever preferred_lft forever inet6 fd23:23:42:0:251d:192a:bb7f:a1f4/128 scope global valid_lft forever preferred_lft forever inet6 fe80::c490:d2ff:fecf:b877/64 scope link valid_lft forever preferred_lft forever Any additional idea? --- Arnaud Cordier --------------- CryptID Freelance cybersecurity engineer - Pentester - Red teamer Tel: +33 (0)6 61 44 82 04 On 10/12/23 22:54, Justas Umbrasas wrote: Hey, we are running a similar setup without an issue (not on k8s). I believe the reason is that the remote dovecot pod is only binding on IPv4 and has no IPv6 configured. This is kind of a hack, however you could try binding the pod to both IPv4 and IPv6 and see if it works. Best, Justas Umbrasas On 2023-10-12 20:25, Arnaud Cordier via dovecot wrote: Dear all, I am running Dovecot 2.3.20 in a Kubernetes cluster. The Dovecot container is exposed behind a Traefik load-balancer, which acts just like HAProxy would, using the Proxy Protocol in order to allow Dovecot to be aware of the real source IP of the client, as follows: Internet <-> Traefik load-balancer <---- Proxy protocol ----> Dovecot My setup works well over IPv4. Oct 12 19:11:33 imap-login: Info: Login: user=<arnaud@xxx>, method=PLAIN, rip=<my_ipv4_public_address> lip=10.42.4.21, mpid=1369531, session=<xxxx> Howevever, if the client originates from an IPv6 address, Dovecot does not seem to take the real IPv6 origin into account and fails. Oct 12 19:09:04 imap-login: Error: haproxy(v1): Client disconnected: Proxied local address is invalid (address=`10.42.4.21', rip=10.42.4.21) A network capture shows that the proxy protocol indeed sends the real IPv6 IP, that should be taken into account by dovecot: ......&.PROXY TCP6 2001:<rest_of_my_public_ip> 10.42.4.21 20200 993 The error seems to be raised in "core/src/lib-master/master-service- haproxy.c" line 553: 551 if (net_addr2ip(*fields, &local_ip) < 0 || 552 local_ip.family != family) { 553 e_error(hpconn->event, "Client disconnected: " 554 "Proxied local address is invalid " 555 "(address=`%s', rip=%s)", str_sanitize(*fields, 64), 556 net_ip2addr(real_remote_ip)); 557 return -1; 558 } 559 fields++; I suppose that the issue is related to the fact that the client originates from an IPv6 then the reverse proxy forwards the connection to Dovecot over IPv4, which results in the "local_ip.family != family" condition to be true. Why is such a restriction implemented ? It is to be noted that I implemented the exact same load-balancer architecture for postfix, which successfully handles an IPv6 real IP over an IPv4 connection. I temporarily fixed the issue by setting an IPv4 only DNS record for my imaps domain name, however, do you think that a fix could be implemented in Dovecot? Kind regards, _______________________________________________ dovecot mailing list -- dovecot(a)dovecot.org To unsubscribe send an email to dovecot-leave(a)dovecot.org

2 1