July 2021 - dovecot - dovecot.org

2FA/MFA with IMAP & postfix/submission
by Alex 16 Jul '21

16 Jul '21

Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail. Are there multi-factor options available? If it is not available, do you have any recommendations on where I should look to do this? All of the links related to this topic appear to be very old, or limited to Linux PAM users.

12 19

function for whitelisting IPs
by White, Daniel E. (GSFC-770.0)[NICS] 16 Jul '21

16 Jul '21

Sebastian, Do you have any examples of such a function and how/where it is used ? -----Original Message----- From: dovecot <dovecot-bounces(a)dovecot.org> on behalf of Sebastian <sebastian(a)sebbe.eu> Reply-To: Dovecot Mailing List <dovecot(a)dovecot.org> Date: Thursday, July 15, 2021 at 01:19 To: 'Mailing List' <dovecot(a)dovecot.org> Subject: [EXTERNAL] Sv: 2FA/MFA with IMAP & postfix/submission Main problem is that not many clients do natively support multifactor. Some clients, do popup a login dialog if the server rejects the password as invalid, which can be used to create a "cheaty variant" of multifactor, but some clients just popup an error dialog and tell the user to just correct password in settings. Some clients even go as long as requiring the user to delete the account with wrong password and set up a new connection. So no, it cannot be relied upon. I have a better idea: Have a function for whitelisting IPs, possible /24's or similiar, where a login to roundcube or other webmail client (with 2FA) will add the IP onto a whitelist for that account. Or perhaps, just "set" the country of the account based on GeoIP. When an account tries to login via IMAP or SMTP, you just check if IP and/or GeoIP country is right, and reject the login as invalid if so not. The only thing a client needs to do to get his IMAP or SMTP client to work again if it stops working, is to login once via the web client. -----Ursprungligt meddelande----- Från: dovecot-bounces(a)dovecot.org <dovecot-bounces(a)dovecot.org> För Alex Skickat: den 15 juli 2021 02:10 Till: dovecot(a)dovecot.org Ämne: 2FA/MFA with IMAP & postfix/submission Hi, I have a dovecot-2.3.13 system on fedora34 with a few hundred IMAP4 accounts, as well as postfix users using submission. Clients are using primarily Outlook on Windows and old squirrelmail. Are there multi-factor options available? If it is not available, do you have any recommendations on where I should look to do this? All of the links related to this topic appear to be very old, or limited to Linux PAM users.

7 10

TLS Security
by Stefan Schumacher 15 Jul '21

15 Jul '21

Hi, I wish to build a new secure email server. It seems I am on the right way – at least I get no more error messages for Postfix – but Dovecot is still making trouble. I am using Dovecot 1:2.3.4.1-5+deb10u6 and I am using ISPconfig 3.25 to do the rough configuring and nano and whats left of my brain to do the finer details. Lets start with what I added to conf.d/10-ssl.conf ssl_cert = </etc/letsencrypt/live/servername/fullchain.pem ssl_key = </etc/letsencrypt/live/servername/privkey.pem ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aR$ ssl_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1 ssl_min_protocol = TLSv1.2 As you can see, I clearly do not want to use TLS before v1.2. I think this is not unreasonable in the year 2021. Now, after the changes I ran Kali (I use it to verify the results of my experiments) and - this is a mailing list, so no screenshots: It says: SSL/TLS Deprecated TLS v1.0 and TLS v1.1 Detection. I get this for the ports 143, 110, 993 and 995. I thought I had done everything one could to disable old TLS-Versions. What am I doing wrong? Yours sincerely Stefan Schumacher

4 6

AW: TLS Security
by Stefan Schumacher 15 Jul '21

15 Jul '21

Hi Justina, Kali tools is of course extremly unprecise. Excuse me, I had a long stressful day and wanted to get this out before the end of the Day. Kali is a rolling release and I keep it up to date by upgrading every few days. I also update the feeds. What I actually use for security scans is the former OpenVAS, which now has been relegated to being a part of the Community Edition of the Greenbone suite. You have seen the values I have in Dovecot. What follows now are my settings in the postfix main.cf. As you can clearly see it, it should prevent connections from TLS below 1.2. Dovecot is of course not very fresh because it's Debian 10 and Debian 11 is just around the corner (a few days). These are the settings of my postfix main.cf. I am very tempted to grab an Image of Debian 11 and install ISPConfig and my Dovecot and Postfix settings there. I am of course open to any other suggestions. A the moment I consider to install a new Bullseye RC2 and then put my configuration on it. I am of course open for any other suggestions. Yours sincerely Stefan smtpd_use_tls = yes smtpd_tls_cert_file = /etc/postfix/smtpd.cert smtpd_tls_key_file = /etc/postfix/smtpd.key smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_tls_eecdh_grade = strong smtpd_tls_protocols= !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_mandatory_protocols= !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_mandatory_ciphers = high smtpd_tls_security_level=may smtpd_tls_ciphers = high tls_preempt_cipherlist = yes smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5 , DES, ADH, RC4, PSD, SRP, 3DES, eNULL smtpd_tls_exclude_ciphers = aNULL, MD5 , DES, ADH, RC4, PSD, SRP, 3DES, eNULL smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 ________________________________ Von: justina colmena ~biz <justina(a)colmena.biz> Gesendet: Mittwoch, 14. Juli 2021 18:50 An: dovecot(a)dovecot.org <dovecot(a)dovecot.org>; Stefan Schumacher <s.schumacher(a)consulting1x1.com> Betreff: Re: TLS Security Interesting. Assuming your "Kali" tools are in fact up to date to test with newer protocols TLS1.2+, is Dovecot compiled against a recent version of the OpenSSL or GnuTLS library or whatever it uses to support the newer TLS protocols? Definitely an outdated cipher issue, on Postfix as well as Dovecot.... On July 14, 2021 6:55:19 AM AKDT, Stefan Schumacher <s.schumacher(a)consulting1x1.com> wrote: Hi, I wish to build a new secure email server. It seems I am on the right way – at least I get no more error messages for Postfix – but Dovecot is still making trouble. I am using Dovecot 1:2.3.4.1-5+deb10u6 and I am using ISPconfig 3.25 to do the rough configuring and nano and whats left of my brain to do the finer details. Lets start with what I added to conf.d/10-ssl.conf ssl_cert = </etc/letsencrypt/live/servername/fullchain.pem ssl_key = </etc/letsencrypt/live/servername/privkey.pem ssl_cipher_list = EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aR$ ssl_protocols = !SSLv2 !SSLv3 !TLSv1 !TLSv1.1 ssl_min_protocol = TLSv1.2 As you can see, I clearly do not want to use TLS before v1.2. I think this is not unreasonable in the year 2021. Now, after the changes I ran Kali (I use it to verify the results of my experiments) and - this is a mailing list, so no screenshots: It says: SSL/TLS Deprecated TLS v1.0 and TLS v1.1 Detection. I get this for the ports 143, 110, 993 and 995. I thought I had done everything one could to disable old TLS-Versions. What am I doing wrong? Yours sincerely Stefan Schumacher -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

1 0

Verifying replication
by Arnold Hendriks 15 Jul '21

15 Jul '21

Dear Dovecot people, I've set up Dovecot replication a couple of years ago. I'm watching the general server health and having Nagios check doveadm replicator status regularly. I'm seeing accounts replicating, disk space usage obviously shows that things work in principle, however, I still wonder whether the replication actually works properly. Accounts I check work, but 1-5% of the messages could easily be missing without me noticing it. These servers have I think about 50K accounts (a lot of them dormant) and between 1 to 2TB of mail. I'm trying to get some more confidence as to whether replication is actually working properly and whether I'm not missing anything that will burn me if I ever have to 'fallback'. Has anyone ever done some verification outside of simply watching doveadm replication stats, to see if they are missing anything ? Eg, I could imagine a process that generates a list of accounts, and then generates hashes on both sides of the replication for each mailbox folder. If the hashes match, the folder gets removed from the list, and once all folders are removed, the account gets removed. Iterating the account list should finally reduce it to 0, or a few extremely high traffic accounts which can be checked manually or be ignored. But I'm trying to avoid reinventing the wheel. Has anyone done anything like this, or can suggest a different approach? With regards, Arnold Hendriks

1 1

Forcing replication - difference is a 0x0D 0x0D 0xA sequence?
by Arnold Hendriks 15 Jul '21

15 Jul '21

I've found a few mailboxes on my system that were being replicated where the mailboxes are not in sync. On server 1 I see: dovecot1:/# doveadm fetch -u s0000000 "size.physical size.virtual" mailbox-guid c92f64f79f0d1ed01e6d5b314f04886c uid 115 size.physical: 1815 size.virtual: 1843 On server 2 I see: dovecot2:/# doveadm fetch -u s0000000 "size.physical size.virtual" mailbox-guid c92f64f79f0d1ed01e6d5b314f04886c uid 115 size.physical: 1805 size.virtual: 1833 Running ' doveadm replicator replicate -f s0000000 "*" ' does not fix the issue. I've compared the mails and the difference appears to be that the primary server (where the mail comes in) has a few occurences of "0D 0D 0A" (hex) which on the replicated server looks like "0D 0A". (ie, \r\r\n was replicated as \r\n ?) Is there a way to force these two messages to be in sync again ? Is the \r\r\n being replicated as \r\n a known issue ? (I'm not sure if I could replicate this, this message dates back to 2007 so probably wasn't even received originally on this server. Replication was configured much later than 2007)

1 0

folders management
by Stephane Magnier 15 Jul '21

15 Jul '21

Hi, Sorry to ask you , maybe a silly question :-) On my folders' architecture, I can see all the folders underneeth each other fodler1 folder2 etc.... I would like to have the possibility to have _folders INTO folders_, like Folder1 Folder2 .......folder 21 ......folder 22 Folders 3 Apparently, this is link to this déclaration :__*_mbox_:/var/spool2/mail/%u. *Is that correct ? is that the "mbox" declaration? or Am I complety wrong ? If I have need to change...I have to change it for what ? * Can I use this new structure with NFS shares ? * What is the backside of it ? Now, if I make this modification.. on an existing dovecot system... , Will it make a true disaster ? or I can change the declaration easily? Thanks and regards,

2 1

Restrict number of mail moved/copied
by Amol Kulkarni 14 Jul '21

14 Jul '21

Hello, I need to restrict number of mail moved/copied by end user using imap in operation. Is there any configuration for that ? Thanks and regards, Amol

1 0

dsync I/O Stalled
by Paolo Daniele 14 Jul '21

14 Jul '21

Hi guys, i've a strange problem between 2 servers. It happened after a changing on our network core routing infrastructure. We've moved to Juniper network and eBGP and iBGP of our server. One of this server is behind a firewall and communicate with another server in another country to sync our emails. Doveadmin replica seems to be fine, but sometimes i get this error message: dsync-server(aaaaa(a)bbb.bb): Error: Timeout during state=sync_mails (send=done recv=mails) It seems like the remote server has troubles to reach our local server but if i do a stupid ping i'm not losing anything. Maybe is there something am i missing? I thought that it could be related to a MTU problem but i'm not so sure and i've increased MTU on the routers involved in routing process without success. I wa missing that both servers are behind a load balancer wich is in our local DC. Can you give me some hints? Regards, Paolo -- Paolo Daniele Intendo s.r.l. E-mail: paolo.daniele(a)intendo.it Business Unit TLCWEB Tel.: +39 0968 430786 Via Coschi, 11 Skype: paolo_daniele1 88046 - Lamezia Terme, Cz Web: http://www.tlcweb.it Italia Web: http://www.intendo.it

2 2

Potential bug: Assumption that POSIX time functions do not clobber errno
by Florian Weimer 13 Jul '21

13 Jul '21

We accidentally ran the dovecot 2.3.14 testsuite on a host where clock_gettime (and probably time and gettimeofday) succeed, but set errno to ENOSYS. This behavior is unusual, but permitted by POSIX: successful function calls can overwrite errno, as long as they don't set it to 0. The relevant log excerpt looks like this: make[3]: Entering directory '/builddir/build/BUILD/dovecot-2.3.14/src/master' for bin in test-auth-client test-auth-master test-master-login-auth; do \ if ! ./$bin; then exit 1; fi; \ done test-common.c:200: Assert failed: suppress == TRUE connection refused: run (ret == -1) .................................. : ok: Connection failed CLIENT: Error: auth-client: conn unix:./auth-client-test: connect(./auth-client-test) failed: Function not implemented connection refused ................................................... : FAILED connection timed out: run (ret == -1) ................................ : ok: Connection failed connection timed out: timeout ........................................ : ok connection timed out ................................................. : ok bad version: run (ret == -1) ......................................... : ok: Connection failed bad version .......................................................... : ok disconnect version: run (ret == -1) .................................. : ok: Internal failure disconnect version ................................................... : ok auth PLAIN disconnect: run (ret < 0) ................................. : ok auth PLAIN disconnect ................................................ : ok auth PLAIN reconnect: run (ret < 0) .................................. : ok auth PLAIN reconnect ................................................. : ok auth PLAIN failure: run (ret < 0) .................................... : ok auth PLAIN failure ................................................... : ok auth PLAIN success: run (ret == 0) ................................... : ok auth PLAIN success ................................................... : ok auth LOGIN failure 1: run (ret < 0) .................................. : ok auth LOGIN failure 1 ................................................. : ok auth LOGIN failure 2: run (ret < 0) .................................. : ok auth LOGIN failure 2 ................................................. : ok auth LOGIN success: run (ret == 0) ................................... : ok auth LOGIN success ................................................... : ok auth PLAIN parallel failure: run (ret < 0) ........................... : ok auth PLAIN parallel failure .......................................... : ok auth PLAIN parallel success: run (ret == 0) .......................... : ok auth PLAIN parallel success .......................................... : ok auth LOGIN parallel failure 1: run (ret < 0) ......................... : ok auth LOGIN parallel failure 1 ........................................ : ok auth LOGIN parallel failure 2: run (ret < 0) ......................... : ok auth LOGIN parallel failure 2 ........................................ : ok auth LOGIN parallel success: run (ret == 0) .......................... : ok auth LOGIN parallel success .......................................... : ok 1 / 49 tests failed make[3]: Leaving directory '/builddir/build/BUILD/dovecot-2.3.14/src/master' “Function not implemented” suggests that dovecot somehow used the clock_gettime (or gettimeofday) ENOSYS error instead of the expected ECONNREFUSED error code. Unfortunately, I have not figured out where this exactly happens. I don't expect that the problematic glibc build escapes to the wild It was a glibc 2.34 development snapshot, and this particular source of ENOSYS errors is gone again. So fixing this is not urgent. Thanks, Florian

1 0