- dovecot - dovecot.org

IMAP account can't save any email with attachment
by Chris Thomas 20 Jul '23

20 Jul '23

Hi, I'm getting a curious problem where if I write a draft without an attachment and click save. It'll work without any issue at all. But if I do the same, then attach a file to the email, it'll sit there for a couple of minutes before timing out (I'm using thunderbird), it'll eventually give you a message saying "Your draft message was not copied to your drafts folder (Drafts) due to network or file access errors." I've got all of dovecots verbose logging turned on. I'm using dovecot as a submission server through to the postfix server to do the actual sending. All the logging is turned on there too. But I can't figure out what the problem is. Is there anything I can look for in the logs that will help me out? chris

2 3

Re: Tons of imap-login processes despite client_limit very high
by Joseph Tam 20 Jul '23

20 Jul '23

https://www.mail-archive.com/dovecot%40dovecot.org/msg85850.html From: D D <pierre.alletru(a)gmail.com> > We're seeing a ton of imap-login processes running even when using high performance mode (https://doc.dovecot.org/admin_manual/login_processes/#high-performance-mode) According to the docs: > > "process_min_avail should be set to be at least the number of CPU cores in the system, so that all of them will be used. Otherwise new processes are created only once an existing one’s connection count reaches client_limit" > > We have process_min_avail=4, client_limit=0 and default_client_limit=200000. So we'd expect seeing only 4 imap-login processes serving a ton of connections each. Yet, we see thousands of imap-login processes (more than half of all the imap processes): > ... > > Is having so many imap-login processes normal with our config? Did we misunderstand the docs or is there something wrong here? > > > default_client_limit = 1048576 > default_process_limit = 200000 > > service imap-login { > # client_limit = 0 # default is 0 > # process_limit = 0 # default is 0 > service_count = 100 This service limit might be your culprit. I wrote about the strange interaction between service_count and process_limit here: https://www.mail-archive.com/dovecot%40dovecot.org/msg85850.html This gotcha should really be documented. Joseph Tam <jtam.home(a)gmail.com>

3 4

Fatal error in http-client.c when passdb is oauth2 and userdb is sql
by Евгений Бахтин 19 Jul '23

19 Jul '23

5 5

-d ${user}@${nexthop} or -d ${recipient}?
by rixati6186＠iturchia.com 18 Jul '23

18 Jul '23

What's the differency between these two lines; 1- flags=DORhu user=vmail:vmail argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -r ${recipient} -d ${user}@${nexthop} 2- flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient} and which one should I use, based on a setup like; Dovecot, Postfix, Postfixadmin, ManageSieve and virtual users hosted in SQL? Thanks in advance.

1 0

dovecot: lda(info@mydomain) - vacation action: discarding vacation response to mailinglist recipient?
by rixati6186＠iturchia.com 18 Jul '23

18 Jul '23

Hello, I'm trying to set auto reply for my email account, through Roundcube and ManageSieve plugin (the plugin itself and its regular filtering works fine), however the auto-reply doesn't arrive to the sender's inbox, when I tested it with sending an email to myself/my server, from my Gmail account, my maillog has a line, stating; Jul 18 15:28:06 mailsrv dovecot: lda(info(a)mywebsite.com)<44812><uikMAlaFtmQMrwAAI6rZ/g>: sieve: msgid=<CA+GnASfyKJDPB-K2uCvxaOL-XQQ7Uv=yJt7sgJSYm-YJzYJSfQ(a)mail.gmail.com>: vacation action: discarding vacation response to mailinglist recipient <mysendermail(a)gmail.com> Any idea would be much appreciated, thank you!

1 1

Re: Fatal error in http-client.c when passdb is oauth2 and userdb is sql
by Евгений Бахтин 18 Jul '23

18 Jul '23

2 1

Re: Fatal error in http-client.c when passdb is oauth2 and userdb is sql
by Евгений Бахтин 18 Jul '23

18 Jul '23

2 1

Tons of imap-login processes despite client_limit very high
by D D 18 Jul '23

18 Jul '23

Hi Dovecot community. We're seeing a ton of imap-login processes running even when using high performance mode (https://doc.dovecot.org/admin_manual/login_processes/#high-performance-mode) According to the docs: "process_min_avail should be set to be at least the number of CPU cores in the system, so that all of them will be used. Otherwise new processes are created only once an existing one’s connection count reaches client_limit" We have process_min_avail=4, client_limit=0 and default_client_limit=200000. So we'd expect seeing only 4 imap-login processes serving a ton of connections each. Yet, we see thousands of imap-login processes (more than half of all the imap processes): $ ps aux | grep imap-login | wc -l 1278 $ ps aux | grep imap | wc -l 2154 We use verbose_proctitle=yes and a there seem to be 2 types of these processes, about half for a single IP and about half we suspect for multiple IPs: $ ps aux | grep imap-log _apt 1941081 0.0 0.0 10420 8700 ? S 14:57 0:00 dovecot/imap-login [84.115.232.178 TLS proxy] _apt 1941589 0.0 0.0 10532 8648 ? S 14:57 0:00 dovecot/imap-login [119.202.86.160 TLS proxy] _apt 1941789 0.0 0.0 10188 8620 ? S 14:57 0:00 dovecot/imap-login [0 pre-login + 2 TLS proxies] _apt 1942144 0.0 0.0 10716 8748 ? S 14:57 0:00 dovecot/imap-login [0 pre-login + 3 TLS proxies] _apt 1942428 0.0 0.0 10800 8712 ? S 14:57 0:00 dovecot/imap-login [5.41.100.37 TLS proxy] ... $ ps aux | grep imap-log | grep pre-login | wc -l 624 $ ps aux | grep imap-log | grep -v pre-login | wc -l 654 Is having so many imap-login processes normal with our config? Did we misunderstand the docs or is there something wrong here? default_client_limit = 1048576 default_process_limit = 200000 service imap-login { # client_limit = 0 # default is 0 # process_limit = 0 # default is 0 service_count = 100 process_min_avail = 4 vsz_limit = 2G inet_listener imap { } inet_listener imaps { haproxy = yes port = 994 } }

2 3

cram-md5, sasl and lua (inheriting technical debt)
by tknb8＠tunenet.dk 18 Jul '23

18 Jul '23

Hello, I am exploring the posibility of migrating an exsisting setup to postfix+dovecot. The issue being that many clients are currently configured for cram-md5 authentication. I am fully aware that this is a really, really, really bad idea, but re configuring all clients at once is not feasible with limited end user support resources. I have a setup running with LUA for the passdb, and everything works with PLAIN login. To keep compatibility with the PLAIN login mechanism i have tried to store {PLAIN} passwords in the DB, since proper secure password storage is incompatible with CRAM-MD5. My issue is that the LUA function auth_password_verify(req, pass) not even seems to be called for cram-md5 logins. Reading through the documentation also seems to indicate that the callenge is not passed to the LUA function making it impossible to compute the hash in LUA or the function req.password_verify(req, row.password, pass). Is my assumption correct that cram-md5 can not work with a LUA script ? Kind regards, Peter K.

2 1

Many IDLE imap processes but very few connections moved to imap-hibernate
by pierre.alletru＠gmail.com 17 Jul '23

17 Jul '23

Hi Dovecot community! I have a strange issue with imap-hibernate. Or more likely it behaves as it's supposed to and it's just that I don't really understand it. I have enabled it, and it works, but for some reason hibernation happens only to a tiny amount of connections, whereas I have a lot of IDLE imap processes. And I can't find any relevant errors in the logs. ## config ## mail_debug = yes verbose_proctitle = yes $ doveconf imap_hibernate_timeout imap_hibernate_timeout = 5 secs $ doveconf -a | grep -A 21 'service imap-hibernate' service imap-hibernate { chroot = client_limit = 0 drop_priv_before_exec = no executable = imap-hibernate extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = imap service_count = 0 type = unix_listener imap-hibernate { group = $default_internal_group mode = 0660 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } ## imap processes ## $ ps aux | grep "dovecot/imap" | wc -l 2214 ps aux | grep "dovecot/imap" | grep IDLE | wc -l 1258 $ ps aux | grep "imap-hibernate" syslog 1571453 0.0 0.0 4748 3156 ? S 15:44 0:00 dovecot/imap-hibernate [18 connections] As you can see here I have 1258 IDLE imap processes (out of 2214 in total), and only 18 connections in imap-hibernate. I'd like to have all IDLE processes to be moved to imap-hibernate in order to save up memory. Any idea why these 1k+ IDLE imap processes are not moved into imap-hibernate? Thank you!

2 1