Re: Dovecot v2.3.21.1 released
On 7/09/24 00:55, Marc via dovecot wrote: On 14/08/24 23:25, Aki Tuomi via dovecot wrote: Hi all, we are releasing a CVE patch release 2.3.21.1. https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Tests failing when attempting to build for both EL8 and 9: When is 2.4 for el9 expected? GhettoForge will release it after the general availablility of 2.4. Others from Dovecot have stated that it will be available directly from the dovecot ce repos once 2.4 is released. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot v2.3.21.1 released
On 14/08/24 23:25, Aki Tuomi via dovecot wrote: Hi all, we are releasing a CVE patch release 2.3.21.1. https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Tests failing when attempting to build for both EL8 and 9: test-failures.c:152: Assert failed: internal_line_match(line, long_log_prefix, TEXT128) test-failures.c:152: Assert failed: internal_line_match(line, long_log_prefix, TEXT128) test-failures.c:152: Assert failed: internal_line_match(line, long_log_prefix, TEXT128) ...this test did not fail in 2.3.21 Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot v2.3.21.1 released
On 15/08/24 00:07, Marc via dovecot via dovecot wrote: we are releasing a CVE patch release 2.3.21.1. https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.21.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot I know about these issues with openssl 3 and if I remember correctly this is solved in 2.4. But when do you expect packages for el9 to be available? El9 packages are in GhettoForge: http://ghettoforge.org/ 2.3.21.1 is being built now and will hopefully be released in a couple of hours. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: SQL Multiple passwords
On 28/07/24 00:49, Jaco Kroon via dovecot wrote: From what I understood from the archive and from my tests, we cannot have multiple passwords for a given account. (I get the error: Password query returned multiple matches) But it looks like it can be done via a PAM module. Does anyone succeeded setup multiple password with PAM or any other method with a SQL backend ? We don't do multiple passwords, but in theory you could by passing the password to the query such that the query can determine which (if any) password to return :). Indeed using the method documented here you should be able to do exactly that: https://doc.dovecot.org/configuration_manual/authentication/sql/#password-verification-by-sql-server This should work with password hashes as well so long as your SQL server has an appropriate function to generate the hash from the passed password (%w) and then compare it to the stored hash. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot refuses to install/run on machine without IPv6
On 7/08/24 07:08, Kurt Fitzner via dovecot wrote: Hi, I just tried to install Dovecot (version 2.3.19.1 9b53102964) on a Debian 12 server I'm building. It failed because Dovecot's default listen address is explicitly "*, ::" and it appears to have no logic to determine if there actually is an IPv6-enabled interface or that IPv6 is enabled on the target machine before it tries to listen on it. If dovecot wants to listen on IPv6 by default, that's neither here nor there, but if this is default behaviour it should check first. How does this affect installation? I would not expect dovecot to work out of the box without having to change at least some settings to suit my specific installation. Most servers nowadays are dual stack so *, :: makes sense as a default. In your case you simply need to edit your dovecot.conf and add (or uncomment) listen = *. > I'm curious if it's the same behaviour for machines without IPv4. Machines without IPv4 enabled are even more of a rarity than ones without IPv6 nowadays. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Debian Bookworm packages, please !
On 27/06/24 06:48, pgnd via dovecot wrote: for anyone interested, for dovecot v2.3.14+ @ Fedora, https://src.fedoraproject.org/rpms/dovecot/blob/rawhide/f/dovecot-2.3.14-opensslv3.patch dovecot hums along nicely. i've not seen a _crash_ in _many_ moons (quick looking thru ~ 18mos of logs) ... I can report the same thing with EL9 and ghettoforge dovecot which uses the same patch. I haven't had any crashes either, but if you're really concerned you can always set Restart=on-failure in the systemd service (I haven't had to yet which says something, imo) That said I don't use the mail crypt plugin so I can't attest to what happens with that. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot logging to files causes issues
On 20/05/24 01:55, Richard Rosner via dovecot wrote: Am 19.05.24 um 15:29 schrieb Friedrich Kink via dovecot: chmod 775 /var/log/dovecot will solve the problem. Without execute permission the process can't access the logfile. Why on earth does a process supposed to write to a file need execution permission? This most certainly is very unwelcome behavior and a bug in any case, no matter if it's intended by the author or not. What the x permission does for directories is different than what it does for files. For directories the x permission allows access to the files in a directory (the "search" permission). Without the x bit you will get a permissions error (just like you're getting). Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot logging to files causes issues
On 19/05/24 04:31, Richard Rosner via dovecot wrote: I have a mailing server setup based on Debian Stable that uses postfix (v3.7.10) for SMTP and dovecot (v2.3.19.1 (9b53102964)) for IMAP. I now wanted to set dovecot to not write to syslog, but to dedicated files in /var/log/dovecot. While everything indicates that this happens successfully as the log files gain in size, I also get lots of these errors: May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: to=, relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, status=deferred (temporary failure. Command output: lda(user): Error: net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't open log file /var/log/dovecot/error.log: Permission denied ) If it would only log the complaints I wouldn't worry, but as long as I don't revert the changes in dovecot's config, mail receiving is at least vastly delayed, most likely stuck alltogether. So how am I supposed to set these settings? I've chainged these settings in /etc/dovecot/conf.d/10-logging.conf: log_path = /var/log/dovecot/error.log debug_log_path = /var/log/dovecot/debug.log log_debug = category=error The whole directory /var/log/dovecot is owned by dovecot:dovecot, permissions on debug.log, error.log and info.log are 644. Check the permissions of the entire path, as dovecot: namei -l /var/log/dovecot/error.log It might be selinux, check your audit.log file, or set selinux to permissive mode and see if it works: setenforce 0 It might also be apparmour (sorry don't have instructions for apparmour). The message basically means that something is preventing the dovecot user from writing to the file, you need to figure out what that is. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Which DKIM application for postfix 3.9.0
On 25/04/24 14:34, Benny Pedersen via dovecot wrote: +1, thanks for dovecot maillist do it right, postfix maillist fails on spf You make a confusing, factually incomplete post with claims that are incorrect and then complain about a lack of clear response on a different list? If you're going to run down the postfix list for your own failure at least have the decency to do it *on* the postfix list. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Is it possible to setup ntlm authentication then proxy it to the mail server ?
Yes, you would need to use the dovecot submission server for this: https://doc.dovecot.org/admin_manual/submission_server/ Most people, however, use their MTA's submission server but use dovecot for the authentication backend: https://doc.dovecot.org/configuration_manual/howto/simple_virtual_install/#simple-virtual-install-smtp-auth Peter On 19/04/24 13:27, karl.l--- via dovecot wrote: Hi, This is my dovecot version: ``` root@freebsdsvr:~ # dovecot --version 2.3.21 (47349e2482) ``` I'm having trouble in making dovecot as proxy to the mail server when using ntlm authentication. My setup looks like this: email client --> dovecot (will act as proxy) ---> mail server so basically the email client will connect to dovecot but dovecot will forward it to the mail server. Proxying using auth_mechanism as PLAIN is working but if I use ntlm authentication it just connects into the dovecot server and dovecot server does not proxy to to the mail server. I tried using passdb driver = sql, passdb driver = static, passdb driver = lua and all of them are working when the email client connects using plain auth, once dovecot authenticates the user it will proxy it to the mail server but when I use ntlm authentication it just connects to dovecot and does not do a proxy to the mail server. You seem to be confusing IMAP with submission. The IMAP protocol is good for fetching mail and as a general interface to the mail storage (or mailbox). IMAP is not used for submitting new mail (except usually for storing a copy in the user's "Sent" folder). Mail submission is done via the "submission" or (the implicit TLS version) "submissions" protocols. This is usually a function of your MTA (e.g. Postfix, exim, Sendmail, etc but generally not Dovecot). So any attempt to submit mail to the IMAP port is flawed. All that said, Dovecot does come with a submission server that can "proxy" mail through to the submission service on your MTA. This can be used in the way you describe (but again it's not IMAP): https://doc.dovecot.org/admin_manual/submission_server/ Most people, however, use their MTA's submission server but use dovecot for the authentication backend. This means that just the authentication credentials are passed through from your MTA to Dovecot and Dovecot answers with a yes/no to the MTA on whether it should allow the submission to proceed. In this case Dovecot is still doing the authentication but no proxy is needed for the actual submission: https://doc.dovecot.org/configuration_manual/howto/simple_virtual_install/#simple-virtual-install-smtp-auth The latter solution is my recommendation unless you have a specific need for using the Dovecot submission server (e.g. BURL support). Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Uppercase username emails are rejected
On 17/04/24 00:51, John Stoffel via dovecot wrote: "Peter" == Peter via dovecot writes: On 14/04/24 12:09, John Stoffel via dovecot wrote: I think you need to update both places, so that your username and password checks are done with lowercase usernames. Generally speaking you want auth to be case-sensitive, but go ahead and try it to see if it fixes the issue. Umm... not for emails you don't. Since the j...@stoffel.org and j...@stoffel.org and j...@stoffel.org are all the same email address... should they be different logins? Not for email... There is a difference between expecting $random_stranger to get the case correct on an email address and expecting a user to get his own email address correct for the purpose of logging in, also keeping in mind that the user will generally get it entered *once* in their MUA and the MUA will store it for future logins expecting the case to be correct is not a huge ask in this scenario. Also keep in mind that the username is not always going to be the same as the email address, in fact Dovecot is perfectly capable of having usernames that are entirely different to the email address that is associated with them. In general, usernames should NOT be case sensitive, that way leads madness. Passwords on the other hand... Both usernames and passwords are part of the authentication credentials. When you allow any authentication credential to be case-insensitive then you decrease the difficulty of any brute-force attack by quite a bit. There is no good reason to make usernames case-insensitive and very good reasons not to. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Uppercase username emails are rejected
On 14/04/24 12:09, John Stoffel via dovecot wrote: I think you need to update both places, so that your username and password checks are done with lowercase usernames. Generally speaking you want auth to be case-sensitive, but go ahead and try it to see if it fixes the issue. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: maybe list rocky and centos9 stream?
On 11/04/24 00:07, Aki Tuomi via dovecot wrote: - We do not build or test 2.3 with RHEL9, as it's not supported with 2.3 (yes, I am aware of the broken patch out there) I assume you're referring to the OpenSSL 3 patch, can you elaborate on why it's "broken"? Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Strange problem with sieve
I could solve the strange problem using a strange approach. I don't try to read the data through stdin in my binary anymore, but I save the stdin into a temporary file (in script, using dd) and then I start my binary with this file as an argument to read data from. Now the binary sees the whole data with headers, multipart correctly encoded in base64, and it can decode it. Probably, stdin data was not correctly sent to binary from script in case of base64 encoded data. I would like to understand - why? But the problem is solved now. Peter On 09/04/2024 20:47, Doug via dovecot wrote: That looks like base64 encoding to me. Possibly your sieve script is parsing the output and truncating the data before handing it off to base64. Doug -Original Message- From: Peter via dovecot Sent: Tuesday, April 9, 2024 2:03 PM To: dovecot@dovecot.org Subject: Re: Strange problem with sieve Thanks for the advise. Yes, the mails are automatically created. Unfortunately, the software that generates them are out of our control. I supposed that it is a base64 code, but if I try to manually pass the text into 'base64 -d' - nothing usable goes out (you can try yourself with the first part of the mail I've posted). Maybe it is salted, but I don't see how to decode it... Peter On 09/04/2024 16:15, Doug via dovecot wrote: -Original Message- From: Peter via dovecot Sent: Tuesday, April 9, 2024 5:18 AM To: dovecot@dovecot.org Subject: Strange problem with sieve Hello, I use Dovecot 2.3.20 on FreeBSD 13.2 (in jail) as a part of iRedMail installation. Some mailboxes are configured for automatic mails processing using sieve (execute :pipe) and a custom binary (started by script). The system was configured and was working correctly during several weeks. Since ~10 days the system starts to work strangely. _*/Some/*_ mails cannot be decoded anymore. No changes at our side, no updates etc. I dumped the content received by my binary, and it looks really strange: pOUc9Z33O0GbfzbW5Mrmi 3L4tTlvKfsD8wP+hc6vN1v1bv+Vx827kW+YX5n/Zxtl240erH4t+nNyeuL1zh92 O0p24nYKd vbtcd1UVyBdkFwztDtrdsIexJ2/Pu71L914vnFdYto+0T7JvoCiwqGm/7v6d+78 U Jxf3lHiU 1B9QO7D1wIeD3IO3S91K68rUy/LLPv/E/6m/3Le8oUK/ovAQ7lDWoaeHow6 3/8z8ubpStTK/ This is a start of one mail. No headers, no readable data. I removed "discard;" from sieve script to put such mails in the mailbox, and the mails look normally: Mime-Version:1.0 Content-Type:multipart/mixed; boundary="=- /3n/zeVGlN5thgeL28RKiw==" --=-/3n/zeVGlN5thgeL28RKiw== Content-Type: multipart/alternative; boundary="=- sE/MdvfJZlakBmrKkcdzCg==" --=-sE/MdvfJZlakBmrKkcdzCg== Content-Type: multipart/related; boundary="=- cgJVnLNlzX5YuD6yaI5USQ==" --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 etc. Really, I have no idea about any direction to explore. The server is totally under my control, I can do anything, but I have no idea how to debug this situation. I tried to redirect such mails to another mailbox and process them there, but I get the same strange data. If I connect Thunderbird to the mailbox - I can read the mails correctly. So, the problem arrives at the moment when the sieve system is invoked - the mail data is corrupted somehow. Any advise will be really appreciated. Peter RE: --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 What has changed is the body content of incoming emails is now base64 encoded. Because you are trying to process these messages with a script, I'm going to guess that the emails in question are automatically generated somewhere. Go back to the process that is creating these emails and disable base64 encoding. Or, add a base64 decode step to the sieve execute script. Doug ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Strange problem with sieve
Thanks for the advise. Yes, the mails are automatically created. Unfortunately, the software that generates them are out of our control. I supposed that it is a base64 code, but if I try to manually pass the text into 'base64 -d' - nothing usable goes out (you can try yourself with the first part of the mail I've posted). Maybe it is salted, but I don't see how to decode it... Peter On 09/04/2024 16:15, Doug via dovecot wrote: -Original Message- From: Peter via dovecot Sent: Tuesday, April 9, 2024 5:18 AM To: dovecot@dovecot.org Subject: Strange problem with sieve Hello, I use Dovecot 2.3.20 on FreeBSD 13.2 (in jail) as a part of iRedMail installation. Some mailboxes are configured for automatic mails processing using sieve (execute :pipe) and a custom binary (started by script). The system was configured and was working correctly during several weeks. Since ~10 days the system starts to work strangely. _*/Some/*_ mails cannot be decoded anymore. No changes at our side, no updates etc. I dumped the content received by my binary, and it looks really strange: pOUc9Z33O0GbfzbW5Mrmi 3L4tTlvKfsD8wP+hc6vN1v1bv+Vx827kW+YX5n/Zxtl240erH4t+nNyeuL1zh92 O0p24nYKd vbtcd1UVyBdkFwztDtrdsIexJ2/Pu71L914vnFdYto+0T7JvoCiwqGm/7v6d+78U Jxf3lHiU 1B9QO7D1wIeD3IO3S91K68rUy/LLPv/E/6m/3Le8oUK/ovAQ7lDWoaeHow6 3/8z8ubpStTK/ This is a start of one mail. No headers, no readable data. I removed "discard;" from sieve script to put such mails in the mailbox, and the mails look normally: Mime-Version:1.0 Content-Type:multipart/mixed; boundary="=-/3n/zeVGlN5thgeL28RKiw==" --=-/3n/zeVGlN5thgeL28RKiw== Content-Type: multipart/alternative; boundary="=- sE/MdvfJZlakBmrKkcdzCg==" --=-sE/MdvfJZlakBmrKkcdzCg== Content-Type: multipart/related; boundary="=-cgJVnLNlzX5YuD6yaI5USQ==" --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 etc. Really, I have no idea about any direction to explore. The server is totally under my control, I can do anything, but I have no idea how to debug this situation. I tried to redirect such mails to another mailbox and process them there, but I get the same strange data. If I connect Thunderbird to the mailbox - I can read the mails correctly. So, the problem arrives at the moment when the sieve system is invoked - the mail data is corrupted somehow. Any advise will be really appreciated. Peter RE: --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 What has changed is the body content of incoming emails is now base64 encoded. Because you are trying to process these messages with a script, I'm going to guess that the emails in question are automatically generated somewhere. Go back to the process that is creating these emails and disable base64 encoding. Or, add a base64 decode step to the sieve execute script. Doug ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Strange problem with sieve
Hello, I use Dovecot 2.3.20 on FreeBSD 13.2 (in jail) as a part of iRedMail installation. Some mailboxes are configured for automatic mails processing using sieve (execute :pipe) and a custom binary (started by script). The system was configured and was working correctly during several weeks. Since ~10 days the system starts to work strangely. Some mails cannot be decoded anymore. No changes at our side, no updates etc. I dumped the content received by my binary, and it looks really strange: pOUc9Z33O0GbfzbW5Mrmi 3L4tTlvKfsD8wP+hc6vN1v1bv+Vx827kW+YX5n/Zxtl240erH4t+nNyeuL1zh92O0p24nYKd vbtcd1UVyBdkFwztDtrdsIexJ2/Pu71L914vnFdYto+0T7JvoCiwqGm/7v6d+78UJxf3lHiU 1B9QO7D1wIeD3IO3S91K68rUy/LLPv/E/6m/3Le8oUK/ovAQ7lDWoaeHow63/8z8ubpStTK/ This is a start of one mail. No headers, no readable data. I removed "discard;" from sieve script to put such mails in the mailbox, and the mails look normally: Mime-Version:1.0 Content-Type:multipart/mixed; boundary="=-/3n/zeVGlN5thgeL28RKiw==" --=-/3n/zeVGlN5thgeL28RKiw== Content-Type: multipart/alternative; boundary="=-sE/MdvfJZlakBmrKkcdzCg==" --=-sE/MdvfJZlakBmrKkcdzCg== Content-Type: multipart/related; boundary="=-cgJVnLNlzX5YuD6yaI5USQ==" --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 etc. Really, I have no idea about any direction to explore. The server is totally under my control, I can do anything, but I have no idea how to debug this situation. I tried to redirect such mails to another mailbox and process them there, but I get the same strange data. If I connect Thunderbird to the mailbox - I can read the mails correctly. So, the problem arrives at the moment when the sieve system is invoked - the mail data is corrupted somehow. Any advise will be really appreciated. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Uppercase username emails are rejected
On 7/04/24 02:34, lua8ds--- via dovecot wrote: When a sender writes my email address with my username uppercase, e.g. usern...@name.com, in the to: field of their MUA, my mail server rejects that email. /var/log/mail.log prints: : host mail.redacted.com[private/dovecot-lmtp] said: 550 5.1.1 > User doesn't exist: usern...@redacted.com (in reply to RCPT TO >command) In the manual, I found that: auth_username_format auth_username_format is for the authentication backend and has nothing to do with receiving mail. You want to change the args line under userdb, add an "L" modifier to username_format, so something like: args = username_format=%Ln ... Alternatively you can probably configure your MTA to lowercase the username before it passes the message off to dovecot. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: DMARC setting change
>>>>> "dovecot---" == dovecot--- via dovecot writes: >> We've changed the list dmarc mitigation to happen unconditionally >> now. dovecot---> What does "mitigation to happen unconditionally" mean? dovecot---> What was changed? Are you talking about changing the dovecot---> policy action? You'll notice a different 'From:' address in the emails from the list. The original author will be in the 'Reply-To:' header. Also Mailman3 strips the original DKIM signature and insert a new one. This used to happen only for senders to the list with a dmarc polcy that would prevent emails getting through; now it's for all senders. Unless you're filtering based on From: you probably won't notice. Peter C ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Dovecot and SNI
On 13/03/24 22:30, Stuart Henderson wrote: I test with this: openssl s_client -connect mail.domain.com:993 -crlf -quie= t That's not a valid test. openssl >=1.1.1 s_client uses SNI by default, with libressl or older openssl you need to use -servername. Indeed, you want: openssl s_client -connect mail.example.com:993 -servername mail.example.com -crlf -quiet -servername works with newer versions of s_client but is required for older versions, if you include it in everything you can't go wrong. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
User-configurable time-based mail deletion in specific folders
Hi I have been wondering about if Dovecot has a feature that would allow users to setup a rule for a given folder, that mails older than X days should be deleted? Or is this something that would need to be done by an external script? I have looked a bit at autoexpunge, and while the basic feature looks to be what I need, it doesn't seem to be configurable down to a specific folder on a single user. -- Peter Reinhold ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Splitting up packages
On 27/01/24 14:31, Larry Rosenman wrote: I'm the maintainer of the dovecot and pigeonhole ports on FreeBSD and am looking to make separate installable packages like the project does for Linux. Can you help me know what needs to go where and what options (if any) change the base? Thanks for any help here. Look at the build instructions for the other distros, e.g.: https://src.fedoraproject.org/rpms/dovecot/blob/rawhide/f/dovecot.spec It shows you what source packages are used, what patches are used, what different packages are produced, all the different commands for the different build stages, what resulting files go in each resulting package, and what extra commands are run at install and uninstall time, etc. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Tests fail 2.3.21 in aarch64 build
Building Dovecot 2.3.21 for aarch64 (building with qemu emulation) I get the following in the test stage: test-file-cache.c:266: Assert failed: file_cache_set_size(cache, 1024) == -1 Panic: file test-common.c: line 211 (test_expect_error_string_n_times): assertion failed: (expected_errors == 0) test-common.c:245: Assert failed: suppress == TRUE Error: Raw backtrace: ./test-lib(+0x693f0) [0x7f10b36943f0] -> ./test-lib(+0x6d8e4) [0x7f10b36988e4] -> ./test-lib(+0x75110) [0x7f10b36a0110] -> ./test-lib(+0x75168) [0x7f10b36a0168] -> ./test-lib(+0x15534) [0x7f10b3640534] -> ./test-lib(+0x152ec) [0x7f10b36402ec] -> ./test-lib(+0x3411c) [0x7f10b365f11c] -> ./test-lib(+0x15e64) [0x7f10b3640e64] -> /lib64/libc.so.6(+0x2c79c) [0x4087579c] -> /lib64/libc.so.6(__libc_start_main+0x98) [0x4087586c] -> ./test-lib(+0x163f0) [0x7f10b36413f0] qemu: uncaught target signal 6 (Aborted) - core dumped I'll provide more info on request. Is this just an issue with the tests or is it an issue with Dovecot itself? Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: lda or lmtp for sieve?
On 20/01/24 12:28, Joe Acquisto wrote: I noticed that many places in the documentation and in examples gleaned from the wilderness, refer to the LDA protocol when discussing sieve. The documentation also mentions that lmtp is preferred over lda, and seems to say in places that sieve will operate without issue in either case. Does it matter to sieve implementation if one uses only lmtp? LDA is older, think of LMTP as a more modern replacement. LDA has to launch a separate process and process one message at a time. LMTP maintains a running service and can stream multiple messages in a single connection, therefore LMTP is a lot more efficient. You will see a lot of bad advice on the internet, or old outdated advice. Tutorials that use LDA is an example of old, outdated advice. Sieve itself doesn't care which one you use, but there are other reasons to prefer LMTP. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: ARM support
Thanks for your reply. I'm now very confused. Looking at https://github.com/dovecot/docker/blob/main/2.3.21/Dockerfile this container clearly just installs the debian package from the community repo. That's why I thought publishing a arm64 debian package would enable a arm64 docker image. Isn't https://github.com/dovecot/docker the source for the official docker images? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: ARM support
I would be fantastic if dovecot could release arm64 debian packages to the community repo, as it would allow fixing a lot of downstream problems: - release of official arm64 docker images - fix other downstream docker images like docker mailserver and mailcow It looks like arm64 is gaining a lot of traction with Apple M series cpus, AWS Graviton, Ampere on eg. Hetzner, etc. As far as I understand the debian packaging setup is not public / available on https://github.com/dovecot ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Broken Docs
The page: https://doc.dovecot.org/configuration_manual/protocols/lmtp_server/ ... has links to the old dovecot wiki which are now broken, specifically the Postfix and Exim links at the bottom of the page. Can someone please port those pages over to the docs and fix the links? Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Replication going away?
Hi, On 2023-11-28 16:20:56 +0100, gerben.wie...@rna.nl wrote: From what version on is replication gone? I am running 2.3.20 and it still there. it will be gone from version 2.4/3.0 onward (see [0]). Best regards, Peter [0] https://doc.dovecot.org/3.0/installation_guide/upgrading/from-2.3-to-3.0 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: 2 users who are the same user
Am 25.11.23 um 23:53 schrieb Michael Grant via dovecot: Error: Mailbox INBOX: Sync failed for mbox: UID inserted in the middle of mailbox (4315358 > 4312144, seq=1, idx_msgs=3212) Maildir to the rescue? https://doc.dovecot.org/admin_manual/known_issues/mbox_problems/ If maildir can fix this and leave it as 2 users (both me!) accessing the same maildir, then that's great. I'd say, Maildir also requires the accounts switched to the same user. Read the linked article and about userdb. But if it is a concurrency problem, it should help. Have this running with 5 virtual users switched to the same system user, all very busy. Dovecot is a great groupware :) -- peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: 2 users who are the same user
Am 25.11.23 um 20:38 schrieb Michael Grant via dovecot: Error: Mailbox INBOX: Sync failed for mbox: UID inserted in the middle of mailbox (4315358 > 4312144, seq=1, idx_msgs=3212) Maildir to the rescue? https://doc.dovecot.org/admin_manual/known_issues/mbox_problems/ -- peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Question about namespaces
Hi J,
On 21.08.23 21:08, J Doe wrote:
My current dovecot.conf is rather basic when it comes to namespaces - I
have one private namespace per user:
namespace inbox {
type = private
separator = /
inbox = yes
hidden = no
list = yes
subscriptions = yes
}
I have some users who connect via more than one client - for instance,
some use Apple Mail in addition to Roundcube. I have noticed that
different mail clients sometimes create similar mailboxes, such as Trash
and Deleted Items. I would like the same mailboxes across any client,
so I am wondering if there is a way in Dovecot to specify the folders
and have the *client* not create them. For instance, a config in
dovecot.conf that specifies a Trash folder and the mail clients cannot
create "Deleted Items", etc. in addition to this.
Is this possible ?
this can be done using the settings in
https://github.com/dovecot/core/blob/main/doc/example-config/conf.d/15-mailboxes.conf
Best regards,
Peter
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: el9 rpms
On 21/06/23 09:40, Steven Varco wrote: Sad, had planed to migrate my dovecot cluster (2x director 2x IMAP from 2.2.36 (CentOS 7) to 2.4 (AlmaLinux 9, when 2.4 is released). So, does anyone already built a STABLE(!) alternative for director? See my previous post to this thread. The Ghettoforge packages are the latest stable (2.3) version of dovecot and are built against CentOS for EL7 and Rocky Linux for EL8 and EL9. The EL9 packages will run just fine on Alma Linux. This includes director. I would encourage you to give it a try on a test machine and if it has any issues let me know. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: el9 rpms
On 1/06/23 20:37, Marc wrote: Is there a specific reason why there are (still) no el9 packages? https://repo.dovecot.org/ce-2.3.17/centos/ https://repo.dovecot.org/ce-2.3-latest/rhel/ GhettoForge has them in the gf-plus repo: https://mirror.ghettoforge.org/distributions/gf/el/9/plus/x86_64/ http://ghettoforge.org/ Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Mailing list update
Dear Aki, On 12.04.23 13:31, Aki Tuomi via dovecot wrote: We finally managed to move from mailman2 to mailman3, and mail archives are now at https://dovecot.org/mailman3/archives and they can be now searched, too. thanks for this. Please let us know if you have face any issues with the mailing list and we'll look into it. Is there a way to keep old links to archived messages (such as https://dovecot.org/pipermail/dovecot/-/.html) intact? Best regards, Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Dovecot submission proxy constraints
Dear Dovecot experts, in 2017 Stephan Bosch mentioned in an email about the Dovecot submission proxy [0]: "The current implementation does require that the proxy has direct access to the user's mailbox for BURL (e.g. by running it on the same host as imap), but that restriction should be resolved soon, allowing for more complex setups." Is the mentioned restriction (access to mailbox) still valid in 2023 or has this constraint been lifted in the meantime? Best regards, Peter [0] https://dovecot.org/pipermail/dovecot/2017-December/110282.html
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 31/12/22 02:58, Jorge Concha C. wrote: Hi, Yes, it works perfectly! Thanks for confirming. I've moved the packages to gf-plus and future updates in Ghettoforge will contain this fix. Peter
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 28/12/22 03:31, Jorge Concha C. wrote: Finally, I found the problem. At build time, I had not installed the 'rpcgen' (RPM) package. Initially, I installed the original RPM of the Rocky-Linux distribution, having the same problem. I gather that the Rocky-Linux community is also creating the dovecot's rpm without 'rpcgen' installed. A little bit of background on this since I've been looking into it. Up through RHEL 7 the rpcgen binary was included in the glibc-common package, which is part of the standard build deps that are installed for all builds. As of RHEL 8 this binary was moved to it's own package and was not installed automatically as it was previously. This means that rquota (quota on NFS) worked fine up through EL7, but was broken for all builds starting with EL8. Since dovecot builds fine without rquota support it appears that the issue never came up before, or at least it never got the notice of Red Hat. The solution, as you point out is simple. rpcgen simply needs to be added as a BuildRequires line in the dovecot.spec file and the package will once again be built with rquota support as it was before. I filed a bug in Red Hat bugzilla, let's see if anything comes of it: https://bugzilla.redhat.com/show_bug.cgi?id=2157045 Peter
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 30/12/22 13:17, Peter wrote: On 30/12/22 07:40, Jorge Concha C. wrote: Hi... rpcgen it's required only at compiling time. Not for execution. The RPM package at https://mirror.ghettoforge.org/distributions/gf/el/9/testing/x86_64/ requiere rpcgen and this is not necesary. I wasn't sure and what I could find seemed to indicate it was required at runtime as well. Can you verify that it works, though? I'll remove the runtime requirement. Feel free to try the packages in gf-testing now, I believe they should work for what you need. I'll move them out to gf-plus once you've confirmed. Peter
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 30/12/22 07:40, Jorge Concha C. wrote: Hi... rpcgen it's required only at compiling time. Not for execution. The RPM package at https://mirror.ghettoforge.org/distributions/gf/el/9/testing/x86_64/ requiere rpcgen and this is not necesary. I wasn't sure and what I could find seemed to indicate it was required at runtime as well. Can you verify that it works, though? I'll remove the runtime requirement. Peter
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 29/12/22 14:01, Peter wrote: On 29/12/22 07:30, Jorge Concha C. wrote: Hi, Yes, same issue. Package installed: dovecot23-2.3.20-1.gf.el9.x86_64.rpm And the solution for you simply involvs installing rpcgen during the configure and build stages? Are there any changes required to configure or build flags? I looked at the config file and that indeed appears to be the case. Can you try the build I just did in gf-testing? https://mirror.ghettoforge.org/distributions/gf/el/9/testing/x86_64/ Peter
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 29/12/22 07:30, Jorge Concha C. wrote: Hi, Yes, same issue. Package installed: dovecot23-2.3.20-1.gf.el9.x86_64.rpm And the solution for you simply involvs installing rpcgen during the configure and build stages? Are there any changes required to configure or build flags? Peter
Re: [SOLVED] Re: Error: Failed to get quota resource STORAGE: quota-fs: quotactl(Q_GETQUOTA, NFS:/home) failed: No such file or directory
On 28/12/22 03:31, Jorge Concha C. wrote: Finally, I found the problem. At build time, I had not installed the 'rpcgen' (RPM) package. Initially, I installed the original RPM of the Rocky-Linux distribution, having the same problem. I gather that the Rocky-Linux community is also creating the dovecot's rpm without 'rpcgen' installed. I'm curious if you would get the same issue with the dovecot23 Ghettoforge packages in the gf-plus repo: http://ghettoforge.org https://mirror.ghettoforge.org/distributions/gf/el/9/plus/x86_64/ If so I wouldn't mind adding rpcgen as a build-dep to see if it helps. Peter
Re: Dovecot v2.3.20 released
On 24/12/22 01:25, Aki Tuomi wrote: Can you confirm that CVE-2022-30550 is patched in dovecot-2.3.20? Thank you. We've decided to fix it for 2.4 release only, so it's not fixed in 2.3.20. That is a surprising decision. The bug does not, in fact, affect that many setups, and we do not consider it to be practically that severe bug. OpenSSL 3.0 support is also planned for 2.4. If you're running RHEL or one of the clones then the Ghettoforge builds have both the CVE-2022-30550 and OpenSSL 3.0 support patched in. The packages are dovecot23 in the gf-plus repository and are available for EL7, 8 and 9. http://ghettoforge.org/ If you're running a different distribution then you can still get the patches by unpacking the src.rpm file (or you can dig them up from the dovecot github) and add them to your own build: http://mirror.ghettoforge.org/distributions/gf/el/9/plus/SRPMS/dovecot23-2.3.20-1.gf.el9.src.rpm Peter
pigeonhole (manage)sieve directory permissions
Hello,
I've tried to find info (apart from looking at the sources) but it
seems this isn't mentioned anywhere.
The setting
plugin {
sieve = file:~/sievedir;active=~/.sievefilter
}
names the directory where the scripts are stored and the symlink
pointing at one.
Right now the sievedir seems to be created 0700 plus some - probably
inherited - g+s. How could I change mode (to 02770 preferably)?
Also the script files are created 0600 by managesieve which really
would be nice to be 0660 instead.
The main problem is that external programs shall stat() .sievefilter
but they only share groups.
Thanks,
g
Re: Permission denied UNIX perms appear ok (ACL/MAC wrong?))
>>>>> "Austin" == Austin Witmer writes: Austin> So, the location of my mail storage Austin> (/mnt/volume1/mailserver/plain/maildir/%d/%n/) is a filesystem Austin> mounted by gocryptfs. Do you think gocryptfs could be at fault Austin> here? Is it automounted? I've seen issues where dovecot tries to access a file before the mount has finished, giving a pmerssions denied error. Peter C
Re: Redhat 9 Repository for Dovecot
On 29/08/22 00:51, Istiak Ferdous wrote: Hello, Thank you for your response. I tried official package and appstream package but both wasn't build with '--with-sodium' flag for argon2 support. So I had to build the package myself. It doesn't actually look like it needs to have --with-sodium and dovecot will auto-detect sodium at build time by default, but it does need to have the lib and devel packages installed. I'll push out a build with sodium for GhettoForge as I see no reason not to have it. Peter
Re: Redhat 9 Repository for Dovecot
On 29/08/22 00:51, Istiak Ferdous wrote: Hello, Thank you for your response. I tried official package and appstream package but both wasn't build with '--with-sodium' flag for argon2 support. So I had to build the package myself. I did announce that GhettoForge has them a couple of weeks ago. https://mirror.ghettoforge.org/distributions/gf/el/9/plus/x86_64/ http://ghettoforge.org/index.php/Usage Peter
Re: convert mdbox to maildir
On 14/08/22 21:47, Marc wrote: So? that is why you have this lmtp not? Afaik was mdbox created to solve the (performance) issues with mbox and maildir etc. So I just wonder what the logics is behind chosing maildir current day. maildir is probably what most people use and should continue to use. There are cases where mbox is still viable but nowadays they are rare edge cases. Basically put mbox was one file for all mail in the mailbox, it served us well in the days of POP when clients would download all the mail from the server and it would be deleted right away on the server-side with no folders and very rarely leaving mail on the server at all. This worked because when a client downloaded the messages they could for the most part just basically stream the entire mbox file straight through the TCP POP connection and then simply delete or truncate the file. Nowadays IMAP is prevalent and so we have multiple folders stored server-side and mail is largely left on the server, so messages need to be accessed in a sort of random-access style instead of just streaming the whole lot of them down at once as used to be done in the POP days. This makes Maildir (where messages are stored one-per-file) much more efficient for storage and access. Most people should probably be using Maildir nowadays, it's a good format and is extremely portable so that other tools can easily recognize and work directly with the Maildir files. There is, however, one major issue with Maildir. Filesystems store files in clusters on disk (and even, I believe on SSD drives), and these cluster sizes have been growing over the years in order to accommodate increasingly bigger file and filesystem sizes. The problem is that when you have 10,000 messages all approximately 500 bytes in size and a 4k cluster size, those messages don't take up 5MB on disk, but rather they take up approximately 40MB on disk because each file (which correspeonds to each message) takes up at least a full cluster on disk. To solve this we now have mdbox which stores many messages (by default 10M worth) in one file, but not so many as to make the file unwieldy for random access of messages. The idea is that we can store way more messages that way in the same given space because we're not wasting most of the disk space on the filesystem having to use a full cluster per message. 10M is not, however, a huge amount of memory to allocate in RAM to manipulate one file with, so storing 10M worth of messages to each file tends to bedome a good compromise between storing all of the messages in one file vs storing one message per file. At the end of the day, though, the storage benefits of mdbox should be weighed against the sheer simplicity and widespread use of Maildir. If you have really huge mailboxes (like ones that contain 50,000 or more messages) then mdbox may be the right solution for you, but most people will be fine with Maildir. Peter
Re: RHEL9 Repository
On 6/08/22 17:10, justina colmena ~biz wrote: I would highly encourage a use of basic https all around: certbot/letsencrypt is currently free and there are many other low-cost options for https in conjunction with any given hosting service or platform. It's in the works, but there's only so much I can do as one person. The important stuff is secure, the site will be when I can get time to work on it. Peter
Re: RHEL9 Repository
The main site doesn't currently support https but the repositories do, also all packages are cryptographically signed and the signing keys are served off of a secure server. The info on the site is public information that doesn't really need to be secure. Peter On 6/08/22 04:18, justina colmena ~biz wrote: /_!_\ The connection to ghettoforge.org is not secure You are seeing this warning because this site does not support HTTPS. _Learn more_ [Go back] [Continue to site] On August 5, 2022 4:06:46 AM AKDT, Peter wrote: For those who have been asking, GhettoForge 9 is now released with dovecot23 packages for all EL9 distributions in the gf-plus repository. These are built against Rocky Linux 9 and should install and run on any EL9 distro including, but not limited to: * Rocky Linux 9 * Red Hat Enterprise Linux 9 * Oracle Linux 9 * Alma Linux 9 * Scientific Linux 9 ...and more This provides the latest stable version of dovecot-2.3.19.1 Please see the instructions at the following link for how to install and run packages from the gf-plus repository: http://ghettoforge.org/index.php/Usage <http://ghettoforge.org/index.php/Usage> ...and let me know if you have any difficulties or questions with these packages. Peter Ajamian -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
RHEL9 Repository
For those who have been asking, GhettoForge 9 is now released with dovecot23 packages for all EL9 distributions in the gf-plus repository. These are built against Rocky Linux 9 and should install and run on any EL9 distro including, but not limited to: * Rocky Linux 9 * Red Hat Enterprise Linux 9 * Oracle Linux 9 * Alma Linux 9 * Scientific Linux 9 ...and more This provides the latest stable version of dovecot-2.3.19.1 Please see the instructions at the following link for how to install and run packages from the gf-plus repository: http://ghettoforge.org/index.php/Usage ...and let me know if you have any difficulties or questions with these packages. Peter Ajamian
Re: RHEL9 Latest Repo?
On 28/07/22 6:55 am, dove...@ptld.com wrote: Any plans or timeline for when there will be a latest repo for RHEL9? I should have Ghettoforge packages out hopefully early next month. Peter
Re: Tools to get a report of which folders have new mail?
On 19/07/22 3:18 pm, Steve Litt wrote: Is there any way I could use doveadm or other tools to create a report that shows all my folders in a hierarchy? See doveadm(1) and doveadm-mailbox(1), specifically the `doveadm mailbox list` command. Also, is there a way to show only those with new mail? Look at doveadm-search(1) and doveadm-search-query(7) for this. You can loop through the list of mailboxes from doveadm mailbox list and pass them one at a time to `doveadm search NEW MAILBOX mailboxname` to see if any messages are returned from the search. Peter
Re: dsync confusion
> "Aki" == Aki Tuomi writes: Aki> This is working exactly as documented. Mbox is the *source* and Aki> maildir is the *destination*, since you are using 'backup' not Aki> 'sync' command. Ah. So sync is bidirectional, backup single directional. >> >> Even this didn't work properly for me. All the messages from all >> the mboxen in ~/Mail ended up in ~/Maildir/cur and the other >> mailboxes ended up with empty cur/ and new/ directories under >> ~/Maildir/xxx/ Aki> Can you try running `doveadm -D sync maildir:~/Maildir:LAYOUT=fs` Aki> after deleting your previous attempt? It seems quite picky. A few mailboxen yeilded errors until I viewed them from an IMAP client. After that, the sync proceeded and created ~/Maildir; but again, all the .../cur/ directories are empty except the top level one. The output is huge: I have several hundred mailboxes with a few dozen to a few thousand messages in each. I've picked out all the lines for one mailbox that has only 21 messages in it: 71:Jul 12 18:58:14 dsync(peterc): Debug: brain M: Local mailbox tree: House guid=77233a11d5d5cc62791c0753e300 uid_validity=1152174120 uid_next=21 subs=no last_change=0 last_subs=0 72:Jul 12 18:58:14 dsync(peterc): Debug: brain S: Remote mailbox tree: House guid=77233a11d5d5cc62791c0753e300 uid_validity=1152174120 uid_next=21 subs=no last_change=0 last_subs=0 385:Jul 12 18:58:14 dsync(peterc): Debug: brain S: Mailbox House: local=/0/0, remote=77233a11d5d5cc62791c0753e300/0/1: mailbox not selectable yet 593:Jul 12 18:58:15 dsync(peterc): Debug: Namespace : /home/peterc/Maildir/House doesn't exist yet, using default permissions 595:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Mailbox opened 601:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Mailbox not found 602:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Mailbox opened 615:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 628:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 642:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 657:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 673:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 690:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 708:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 727:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 747:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 768:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 790:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 813:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 837:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 862:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 888:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 915:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 943:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 972:Jul 12 18:58:15 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1002:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1033:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1065:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1098:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1132:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1167:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1203:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1240:Jul 12 18:58:16 dsync(peterc): Debug: Mailbox House: Couldn't open mailbox in list index: Refresh-flag set 1278:J
Re: [Dovecot-news] CVE-2022-30550: Privilege escalation possible in dovecot when similar master and non-master passdbs are used
On 8/07/22 7:16 pm, Aki Tuomi wrote: Not all CVEs are "that serious". CVE scores are problematic, you can have a solid 10.0 CVE score that affects practically no one, and you can have a 3.8 CVE that affects ~everyone using the software. This particular bug requires a quite specific setup, and also provides a sensible workaround for it. It will be included in upcoming 2.4 release, we do not currently see any pressing reason to rush out a CVE patch release for this. I've applied the patch to the GhettoForge packages for dovecot23 (el7 and 8) and dovecot22 (el7) for those who want a patched release for the EL platform. Peter
Re: Redhat 9 Repository for Dovecot
On 8/07/22 4:49 am, Istiak Ferdous wrote: Hello, Redhat 9 is publicly released for some time. Is there any plan to provide repository for it? GhettoForge will be releasing for EL9 once Rocky Linux 9 drops. In the meantime there is dovecot 2.3.16 in appstream. Peter
Re: Dovecot v2.3.19 released
On 12/05/22 3:38 am, Alan Swanson wrote: On Tue, 2022-05-10 at 09:33 +0300, Aki Tuomi wrote: Hi all! We are pleased to release v2.3.19 of Dovecot. On Sun, 2022-02-06 at 14:25 +, Alan Swanson wrote: On Sat, 2022-02-05 at 14:55 +1300, Peter wrote: On 8/12/21 2:12 am, Alan Swanson wrote: Reverting commit "fts: Use mailbox-match-plugin API for fts_autoindex_exclude" resolved this core dump in lib20_fts_plugin.so for me. https://github.com/dovecot/core/commit/9d02ac2e4232cc69bc37344c6341674b87078301 Is this fixed yet in 2.3.18? No, still broken and core dumping (there's been no changes to src/plugins/fts/fts-storage.c) and the commit still needs reverted on 2.3.18. Unfortunately this is still not fixed in 2.3.19 and continues to core dump at fts_user_autoindex_exclude(). Reverting the referenced commit still fixes it. Thanks for the update, I'm keeping the reverted commit in my build until it gets fixed. Peter
Re: Sv: Does disabling POP3 just mean removing it from the protocols list?
Honestly, I think that's too much work for almost no gain. Bots can do password guessing just as easily via IMAP or SMTP AUTH so there is little reason to think that trying to block POP3 access to them will do any extra good at all. If you want to put rate limiting in place then that's all good but you'd best do it with all your entry points, not just POP3, and there's no practical reason to actually prevent a user from using POP3 if that's what they want (it limits features they have access to, nothing more). Peter On 2/03/22 1:23 pm, Sebastian Nielsen wrote: However, you SHOULD IMHO lock the access so it has to be manually opened for each user that wants it. Another way is to do a PTR lookup on IP and [DROP] the packet if its not a google IP. And then have a IP restriction on IMAP and also 587/SMTP Auth. This because there is bots out there that guess passwords and then send spam. By locking access for POP3 by Google IP, you ensure it can only be used with the fetch feature of Gmail (which do have account-wise rate-limits to prevent password hacking). In this way, you increase security. Of course it must be combined with IP restrictions and firewalling for IMAP and Auth on 587 aswell. -Ursprungligt meddelande- Från: dovecot-boun...@dovecot.org För Harlan Stenn Skickat: den 2 mars 2022 01:15 Till: Peter ; dovecot@dovecot.org Ämne: Re: Does disabling POP3 just mean removing it from the protocols list? The reason to support POP3 is that if you forward email to another account and that includes any spam, you are gonna get dinged. If folks want to read their email from gmail, they really need to suck that email over via POP to avoid this problem. H On 3/1/2022 3:13 PM, Peter wrote: The only modern reason I can think of to continue to support POP3 is that gmail's email fetch feature only works over POP3, so if you want people to be able to import their email from your server to gmail or google workspace then you should probably continue to support POP3. Peter On 2/03/22 10:54 am, Sean McBride wrote: Hi all, Hopefully a simple question. If I want to disable POP3 support (because everyone is using IMAP anyway), it is just a matter of removing |pop3| from the |protocols| setting in dovecot.conf? Are there side effects or other considerations I should be aware of? Thanks, Sean
Re: Does disabling POP3 just mean removing it from the `protocols` list?
The only modern reason I can think of to continue to support POP3 is that gmail's email fetch feature only works over POP3, so if you want people to be able to import their email from your server to gmail or google workspace then you should probably continue to support POP3. Peter On 2/03/22 10:54 am, Sean McBride wrote: Hi all, Hopefully a simple question. If I want to disable POP3 support (because everyone is using IMAP anyway), it is just a matter of removing |pop3| from the |protocols| setting in dovecot.conf? Are there side effects or other considerations I should be aware of? Thanks, Sean
Re: Dovecot v2.3.17.1 Released
On 7/02/22 7:21 am, Peter wrote: On 7/02/22 3:25 am, Alan Swanson wrote: Is this fixed yet in 2.3.18? No, still broken and core dumping (there's been no changes to src/plugins/fts/fts-storage.c) and the commit still needs reverted on 2.3.18. Thanks, I'll keep that patch in place in my build for now, then. There were some changes to fts-storage.c, I had to rebase the patch for them, but not seemingly significant to this issue. Peter
Re: Dovecot v2.3.17.1 Released
On 7/02/22 3:25 am, Alan Swanson wrote: Is this fixed yet in 2.3.18? No, still broken and core dumping (there's been no changes to src/plugins/fts/fts-storage.c) and the commit still needs reverted on 2.3.18. Thanks, I'll keep that patch in place in my build for now, then. Peter
Re: How to "activate" a mail directory?
Hello Aki, the command works and shows the full path to the folder. However, "dovecot mailbox list -s -u " did not list the mailbox, so I tried to subscribe to it. It's listed now, but I still cannot subscribe to it using Thunderbird. I'm using dovecot to archive my emails locally, using getmail to receive mails from my provider and managing these using Thunderbird (IMAP-Server: local Dovecot, SMTP-Server: remote). Kind regards, Peter Am 05.02.22 um 21:22 schrieb Aki Tuomi: On 05/02/2022 12:08 Peter Nabbefeld wrote: Hello, as I need a mailbox locally only just for filtering, I've tried to manually create it (using Maildir as backend): 1. Created a folder in the appropriate location under /home/vmail with subfolders cur, new, tmp. 2. Set the same user:group as for the other folders (i.e. vmail:vmail). 3. Restarted Dovecot and Email-Client (Thunderbird). However, I cannot subscribe to the new folder. What am I missing here? Kind regards, Peter You sure you put it in right place? You can check the path with doveadm mailbox path -u username MailboxName it does not have to exist to check the path. Aki
How to "activate" a mail directory?
Hello, as I need a mailbox locally only just for filtering, I've tried to manually create it (using Maildir as backend): 1. Created a folder in the appropriate location under /home/vmail with subfolders cur, new, tmp. 2. Set the same user:group as for the other folders (i.e. vmail:vmail). 3. Restarted Dovecot and Email-Client (Thunderbird). However, I cannot subscribe to the new folder. What am I missing here? Kind regards, Peter
Re: Dovecot v2.3.17.1 Released
On 8/12/21 2:12 am, Alan Swanson wrote: On Tue, 2021-12-07 at 12:09 +0100, Frank Elsner wrote: On Tue, 7 Dec 2021 12:44:33 +0200 (EET) Aki Tuomi wrote: We are happy to announce 2.3.17.1 patch release of Dovecot. This contains some fixes for issues found after 2.3.17 release. I still get the old error: Dec 7 12:05:02 christo dovecot[481494]: master: Dovecot v2.3.17.1 (476cd46418) starting up for imap Dec 7 12:05:17 christo dovecot[481540]: imap-login: Login: frank, 192.168.28.84, TLS Dec 7 12:05:18 christo dovecot[481540]: IMAP(frank,192.168.28.84): Fatal: master: service(imap): child 481654 killed with signal 11 (core dumped) [SNIP] Message: Process 481654 (imap) of user 1953 dumped core. Stack trace of thread 481654: #0 0x7fbd353c32cb fts_user_autoindex_exclude (lib20_fts_plugin.so + 0xa2cb) #1 0x7fbd353cc3b6 fts_mailbox_allocated (lib20_fts_plugin.so + 0x133b6) #2 0x7fbd35895d1c hook_mailbox_allocated (libdovecot-storage.so.0 + 0x62d1c) Reverting commit "fts: Use mailbox-match-plugin API for fts_autoindex_exclude" resolved this core dump in lib20_fts_plugin.so for me. https://github.com/dovecot/core/commit/9d02ac2e4232cc69bc37344c6341674b87078301 Is this fixed yet in 2.3.18? Peter
Re: spf helo pass
On 1/01/22 9:57 pm, Benny Pedersen wrote: its basicly just statistik you say above You seem to think you can just ARC sign the message and everything will be rosy. This is not the case, ARC needs to be implemented on the receiver side or it will be completely ignored. It will takes yeras for it to be widely adopted. 1. Check the inbound SPF, DKIM and DMARC and reject the mail if it doesn't pass. check spf helo, spf mfrom, check dkim, check arc in that order, but do not reject, current its only meta data collected to dmarc policy with can reject if sender wants it rejected, but this should relly not be rejected if its arc-signed / arc-sealed, this indicate a maillist where reject is not best way to solve spamming Sure check for ARC as well. The point is to reject anything that might be SPAM because you are going to be DKIM signing it yourself and you don't want to be forwarding SPAM. 2. Other anti-spam measures to try to absolutely minimize the amount of SPAM that you end up forwarding. its possible to unsubscribe So you expect a spammer to unsubscribe? makes things worse makes things worse And yet as I said, it's the only way to guarantee that the message will pass on the recipient side. ARC won't do that. I didn't say it was a great solution, I said it's the *only* solution. 5. Do any other alterations, such as adding list-* headers modifying the Subject: header, etc. does not break dkim when adding new headers, but change signed headers does Wrong. Adding headers *can* break dkim. This is because the lack of headers or NULL headers can be signed. 6. DKIM sign the message from the domain you rewrote the From: header to. perfect forged mail can be tested in dkim adsp Which is why you check the original signature and reject if it doesn't pass. 7. Rewrite the envelope sender to your domain name. normal for maillists, does not break spf specs It's something that you have to explicitly tell your MTA to do, and it certainly wasn't "normal" before SPF was a thing. 8. Send out the message. and hope for no spf helo, spf pass if its spam :) Again, why you try to reject SPAM to begin with. The above assumes properly implemented SPF, DKIM and DMARC records for your domain. define properly I'm not going to go into that level of detail here. There are many many resources on the internet which can tell you how to set up these thigns properly. That is the *only* way you can be fully certain that the forwarded message will pass SPF, DKIM and DMARC checks and therefore have the best chances of being received by the recipient. Anything else relies on implementation specifics of the sender and/or the recipient MTAs which may or may not make that possible. you need more meta data on diffrent maillists if you write this above Nope, this has nothing to do with the mail list. This has to do with different practices of the sending MTA and recipient MTA. The mail list sits in-between the two and must reconcile with various different policies of the sender (which can be determined) and how the recipient will check those policies (which generally cannot be determined). we are OFF Topic, take debate offline from maillist By all means. Just stop trying to claim that ARC will solve all the problems, it won't. I realize that mailing lists likely do not want to implement all of the above steps, but ARC is not a magic bullet that can fix the issues shown, there is no magic bullet and so you either accept that a number of messages will, depending on circumstances, not make it to the recipient, or you take drastic measures to resign everything so that the recipient MTA is happy. Peter
Re: spf helo pass
On 1/01/22 12:56 am, Benny Pedersen wrote: if maillist all did the arc seal/ arc sign, before thay break dkim, then its still possible to verify orginal sender trust, bingo its just sad nearly all make it worse by dkim sign all forwarded mails, thay miss the dkim private key mostly to do this, no ? :=) The problem is there is a not insignificant number of recipient MTAs that check SPF/DKIM/DMARC but do not recognize ARC yet. If you rely on ARC signing then these MTAs will likely reject your mail. This means that the only reliable way to pass SPF, DKIM and DMARC if you're forwarding mail is: 1. Check the inbound SPF, DKIM and DMARC and reject the mail if it doesn't pass. 2. Other anti-spam measures to try to absolutely minimize the amount of SPAM that you end up forwarding. 3. Remove any existing DKIM signature that includes the From: or Reply-To: headers or any other header or content that you will be modifying in the message. 4. Rewrite the From: header to your domain name, add a Reply-To header with the original From: header's content. 5. Do any other alterations, such as adding list-* headers modifying the Subject: header, etc. 6. DKIM sign the message from the domain you rewrote the From: header to. 7. Rewrite the envelope sender to your domain name. 8. Send out the message. The above assumes properly implemented SPF, DKIM and DMARC records for your domain. That is the *only* way you can be fully certain that the forwarded message will pass SPF, DKIM and DMARC checks and therefore have the best chances of being received by the recipient. Anything else relies on implementation specifics of the sender and/or the recipient MTAs which may or may not make that possible. Peter
Re: spf helo pass
On 31/12/21 4:32 am, dove...@ptld.com wrote: DMARC breaks on dovecot mailing list. That is not always the case. Indeed your message explicitly passes DMARC. DMARC does not break on postfix mailing list. This is not true either. I have had several messages fail DMARC from the postfix list. Having a mailing list that doesn't break DMARC is possible. Yes, but it requires rewriting the From: header (among other things). Having an SPF entry for the HELO domain, while it wouldn't hurt, will not help with DMARC. DMARC will only look at it if the domain matches the domain in the From: header, and so unless the message has a From: header with a dovecot.org domain then no amount of SPF records under dovecot.org will help here. The reason that the postfix list (and indeed this list) often times passes DMARC is because the messages are forwarded un-altered, and as such the DKIM signature passes. As long as teh message is originally DKIM signed by the same domain as that in the From: header then it will pass DMARC regardless of SPF. This, of course, is heavily dependent on the proper usage of DKIM by the original sender. Peter
Re: Searching 30 GB mailbox
Am 03.12.21 um 13:34 schrieb Einar Bjarni Halldórsson: Why are you still going through Dovecot for this ? @ 4.5 million messages you could just reprogram your app to search solr directly, it will return the uid of the message and you can use that directly in imap uid fetch. That is a good idea. If this becomes a showstopper, that's one way we could solve this. Below link to a javascript "app", that does it this way. When dovecot caches are warm, it is very quick. That on a not so big a number of mails, but still quite impressive :) https://gist.github.com/hungerburg/00d582bf1a6bf3c622797bf5e759f75b -- peter
Pigeonhole bug: corrupted redirected emails
Hello,
(Please CC me on any replies since I'm not subscribed to this mailing
list.)
I'm writing to report a bug that I just ran into, involving
Sieve/Pigeonhole message redirections. I recently added a rule
involving redirections and the redirected messages were getting
corrupted. I traced the issue down to the fact that an Mbox-style
"From " header line was getting intermixed with the message headers --
note the entry between the two "Received:" headers in this example,
which shows the text being delivered to the MTA on stdin:
X-Sieve: Pigeonhole Sieve 0.4.24 (124e06aa)
X-Sieve-Redirected-From: peter
Delivered-To: peter
Received: from dovecot
by newton.cx with LMTP id xxx
for ; Thu, 01 Jul 2021 04:32:50 +
From pe...@newton.cx Thu Jul 01 04:32:50 2021
Received: from xxx
by newton.cx with esmtpsa xxx
(Exim 4.94.2)
(envelope-from )
id
for pe...@newton.cx; Thu, 01 Jul 2021 04:32:50 +
Message-ID:
Subject: qqtestqq
This was happening with trivial test messages, and trivial Sieve rules,
but I can provide specifics if they would be helpful.
Versions: CentOS 7.9.2009; Dovecot 2.2.36; Pigeonhole 0.4.24; Exim
4.92.2.
Below I've added the output of `dovecot -n`. My `sendmail_path` setting
was empty before, but as a workaround I've set it to a wrapper script
that strips out everything before the `From `, "solving" the problem.
Thanks so much for building Dovecot, I've been using it with great
success for more than a decade!
Best,
Peter
=
# 2.2.36 (1f10bfa63): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.24 (124e06aa)
# OS: Linux 4.14.210-rh241-20201203010913.xenU.x86_64 x86_64 CentOS
Linux release 7.9.2009 (Core) ext3
# Hostname: newton.cx
auth_username_format = %Ln
mail_location = mdbox:/var/spool/mail/%n
mail_plugins = zlib
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-
character vacation subaddress comparator-i;ascii-numeric relational
regex imap4flags copy include variables body enotify environment
mailbox date index ihave duplicate mime foreverypart extracttext
mbox_write_locks = fcntl
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 =
separator = .
type = private
}
passdb {
driver = pam
}
plugin {
recipient_delimiter = +
sieve = ~/.dovecot.sieve
sieve_before = /etc/dovecot/dspam.sieve
sieve_dir = /var/lib/sieve-users/%u
sieve_global_dir = /etc/dovecot/sieve-global
zlib_save = gz
zlib_save_level = 7
}
protocols = imap pop3 lmtp sieve
sendmail_path = /usr/sbin/dovecot-sieve-sendmail.sh
service imap-login {
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
}
service managesieve-login {
inet_listener sieve {
address = 127.0.0.1
port = 4190
}
}
service pop3-login {
inet_listener pop3 {
port = 0
}
inet_listener pop3s {
port = 995
ssl = yes
}
}
ssl_cert =
CA certs for Dovecot-as-client (proxy)
Hi, When using proxy=y, ssl=yes (Dovecot 2.3.13) I consistently get this logged when trying to validate the remote server cert. "Disconnected by server: Connection closed: Received invalid SSL certificate: unable to get local issuer certificate: /C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2 (check ssl_client_ca_* settings?)" As I read the 2.3.x documentation (and the error logged) Dovecot needs to have the trusted CA cert with ssl_client_ca_file or ssl_client_ca_dir. So, I've tried every combination of putting the cert (and the GlobalSign root CA signing it) in ssl_client_ca_dir and individually and as a bundle in ssl_client_ca_file without luck. But even though I can verify the cert with "openssl s_client -connect" and with "openssl verify", no matter what I put in the ssl_client_ca_* settings it seems Dovecot just ignores it. It does complain though, if I point it to a non-existent file, but not if I just fill the file with invalid cert data which can't be parsed. I end up getting in doubt whether it consults the cert data at all. I'm a bit at loss on how to debug this further, short of running it in gdb. "verbose_ssl" doesn't really say anything about the process of find a CA cert to check with. Have I misunderstood the config? /Peter
Re: Obtaining the IMAP GUID from a sieve script
On 18 Jan 2021, at 04:12, Jochen Bern wrote: (Also, you can legally have several e-mails with the same Message-ID in your mailbox; e.g., someone addressed it to two aliases that both expand to you, just to name one possibilty where *both* go through *sieve* as well.) On 18.01.21 12:18, @lbutlr wrote: I delete duplicates before they are delivered to a mailbox. From using doveadm-deduplicate, I remember that with message-Id as criterion, it would delete too much for my taste, of what makes a duplicate. -- peter
Re: Using dovecot with RoundCubeMail - where is the information for new mail in (blue coloured) directories?
Am 19.12.20 um 15:53 schrieb David Morsberger: Phil, I looked around and this is deep in the Roundcube service side code. It is detecting a new message in a folder since the last time you viewed the contents of the folder. I see has the folder list items are changed through css and how the server side code is receiving the request to check for recent. It get complicated after that. I cannot determine if it is keep state in roundcube or making a call to the IMAP provider. I am leaning to roundcube state. The server would be hard pressed: Several users may idle in the same mailbox. If a message is new, then for whom exactly? Thunderbird has a css selector to match "newMessages" too: It can be used from userChrome.css to highlight folders, where there are messages, that have not been there, when the folder was last opened. It wont ever match the folder that is currently opened. This propertry is pure client side state by definition. Peter On Dec 19, 2020, at 12:19 AM, Philip Rhoades <mailto:p...@pricom.com.au>> wrote: David, On 2020-12-19 00:08, David Morsberger wrote: Phil, Are you trying to find out how dovecot marks emails as unread? No - I am trying to work out how New Unread Mails are highlighted in blue - see the attached partial screen capture - the two blue-highlighted RCM folders are highlighted in blue AND are also in bold - folders with OLD but UNREAD mails are just in bold. I want to create a script or find out some way of marking a folder blue according to the datestamp of the most recent mail in the folder. Does that make sense? Thanks, Phil. Assuming you are using maildir format, it appears to be encoded as flags in the email filename on disk. It’s briefly covered in 'Filename examples' https://wiki2.dovecot.org/MailboxFormat/Maildir And in 'What can I put in info?' https://cr.yp.to/proto/maildir.html On Dec 17, 2020, at 7:12 PM, Philip Rhoades wrote: Benny, On 2020-12-18 09:28, Benny Pedersen wrote: Philip Rhoades skrev den 2020-12-17 22:14: Every few years I try to work this problem out User-Agent: Roundcube Webmail/1.4-rc1 please upgrade first It is a long-standing problem and upgrading RCM is not a solution . . - occasionally I would like to re-mark a dir as having new mail so that the dir shows up as blue-coloured in RCM. please dont modify mails outside of imap protocol, Then how do I do what I want with IMAP? if you use roundcube it will not be needed to mangle shell accounts That comment doesn't make sense . . Every time I Google in vain and then have a go at working it out myself if google have no answer to it, its simple not supported Quite frequently not true . . but the only thing I can see is that there is a change in the appropriate dir dovecot.index.log file after having the blue dir clicked on dont mangle files outside of imap protocol You already said that - what is your solution then? (and the colour of the dir name changes back to black) - so is the information stored somewhere in RCM itself? no OK, overall not a very helpful response . . but thanks anyway. P. -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: p...@pricom.com.au -- Philip Rhoades PO Box 896 Cowra NSW 2794 Australia E-mail: p...@pricom.com.au <mailto:p...@pricom.com.au>
quota-status for outgoing mail (Dovecot/Postfix)
[Dovecot version 2.3.11.3 (502c39af9)] Hi all, I’m using Dovecot’s quota-status service to let Postfix check the recipient’s quota before accepting emails following the guide here: https://blog.sys4.de/postfix-dovecot-mailbox-quota-en.html <https://blog.sys4.de/postfix-dovecot-mailbox-quota-en.html>. This works well for inbound emails. I would like to set up something similar for outbound email, i.e. if a user is over quota, they should not be allowed to send new emails. At the moment, the setup is in a bit of an inconsistent state: Users that have exceeded their quota are still able to send outbound emails but saving them in their Sent folder will fail leaving them without a copy. I have tried using Dovecot’s quota-status in Postfix’s smtpd_send_restrictions but didn’t get this to work. A quick look at the Dovecot source code seems to suggest that the quota-status plugin is only checking the recipient address: https://github.com/dovecot/core/blob/master/src/plugins/quota/quota-status.c#L135-L146 <https://github.com/dovecot/core/blob/master/src/plugins/quota/quota-status.c#L135-L146> and https://github.com/dovecot/core/blob/master/src/plugins/quota/quota-status.c#L109-L111 <https://github.com/dovecot/core/blob/master/src/plugins/quota/quota-status.c#L109-L111>. I suspect it’s not possible to use the quota-status service to control outbound email but thought I’d ask to confirm. I’m wondering if there’s a different way to achieve this? Thanks Peter
Re: Any RPMs for aarch64 available?
On 12/4/20 4:29 AM, David Pottage wrote: On 2020-12-03 21:41, Peter Cooper Jr. wrote: Hey, I really appreciate Dovecot being available with standard repos in repo.dovecot.org. I'm currently using the "CentOS 7" one on Amazon Linux 2 and it works great for x86_64. I'm wondering if there are any plans for also providing arm builds (aarch64) at some point? Or if they're available somewhere else already? I may play around with compiling things myself, but just downloading an official package is generally the easier way to go so I thought it couldn't hurt to ask. It won't help you for CentOS, but the Debian project includes Arm64 (AKA aarch64) as one of their standard supported processor architectures and dovecot is one of their many standard supported packages. eg: https://packages.debian.org/stretch/dovecot-core Is Arm64/aarch64 an official supported architecture in CentOS? If so I would look in the standard repositories for dovecot packages. If not then I would suggest that it is not a good idea to use an unsupported Disto/Arch combo unless you are very familiar with building everything from source. Well, I'm actually on Amazon Linux 2, which is similar to (but isn't quite the same as) RHEL/CentOS 7. Dovecot *is* in the standard packages, but it's version 2.2.36-6.amzn2.1 and I was hoping to be on the latest Dovecot 2.3 (which is what I'm doing now on my x86_64 server by just adding repo.dovecot.org to my repo list). But maybe I should just stick with what's built-in as you suggest if I want to make my life easier. I'm not afraid of building from source, and in fact am already working on doing that for Postfix. (And then I can get really crazy by trying to link it against Openssl 1.1.1 rather than the the 1.0.2 that's on the system by default.) I might just try building my own rpms (as a learning experience for myself if nothing else), but it looks like under the source RPMs in http://repo.dovecot.org/ce-2.3-latest/centos/7/SRPMS/2.3.11.3-4_ce/ it only has dovecot and dovecot-imaptest but not dovecot-pigeonhole, so it may be even more of an adventure than I thought. Is the process that makes RPMs for the repo.dovecot.org site a part of the public Github somewhere? I can't find it there (though maybe I'm just not looking in the right place). I'd like to reference it at the very least if I could to see if I could replicate it for aarch64. Thanks everybody for your thoughts! -- Peter
Any RPMs for aarch64 available?
Hey, I really appreciate Dovecot being available with standard repos in repo.dovecot.org. I'm currently using the "CentOS 7" one on Amazon Linux 2 and it works great for x86_64. I'm wondering if there are any plans for also providing arm builds (aarch64) at some point? Or if they're available somewhere else already? I may play around with compiling things myself, but just downloading an official package is generally the easier way to go so I thought it couldn't hurt to ask. Thanks, Peter
Re: Looking for a guide to collect all e-mail from the ISP mail server
Am 26.10.20 um 21:55 schrieb Robert Schetterer: see https://blog.sys4.de/abholdienst-fur-mail-de.html OP considers his/her ISPs spam/antivirus filter adequat. Doing such on his/her own burdens the setup with quite some maintainance. Perhaps though, getmail trumps fetchmail, I don't now. -- peter
Re: Looking for a guide to collect all e-mail from the ISP mail server
Am 26.10.20 um 11:24 schrieb R. Diez: Hello R, I only wrote about the incoming side - of course, you also want to send mail to remote users, and that includes users with an address of …@myisp.com. They will go to the ISP and be fetched to local from there. That is not what I had in mind. My users will not go to the ISP and fetch their e-mails from there. They will always go to my internal mail server. If a user is on the road, he/she will connect with OpenVPN first. Probably I could have said that better: fetchmail will fetch those mails from the ISP, same as any other mails to some...@your.site - the Inbox at your ISPs will always be empty, your users will only interact with the dovecot instance on premise. There is some inefficiency, the price for a simpler setup. I have seen Microsoft Exchange setups that carried on working locally if the Internet connection was down. If Microsoft can do that, I want to have it too. 8-) With some tinkering, you can configure your local relay smtp to deliver those locally, To be more clear - if you have a local smtpd too (not just dovecot and fetchmail, postfix perhaps), that sits between your users MUA and your ISPs smtpd, you can make it recognise some...@your.site as a "local" account and have those mails delivered locally. You have to set up some mappings though, that replicate the ones in your fetchmailrc. Start of a HOWTO: 1) Install dovecot, create virtual accounts for all of your users 2) Install fetchmail, make it pull the ISPs IMAP and deliver locally 3) Install postfix as a smart relay and deliver locally to locals Feel free to fill in the details ;) -- peter
Re: Looking for a guide to collect all e-mail from the ISP mail server
At 26 October, 2020 Sebastian Nielsen wrote: > > >> why not just point them at a hosting service like google apps, and let > google keep things up to date? Oh they most certainly do :) > Costs money, and also the problem is that gmail imposes heavy spam filters > and "reputation blocks" meaning smaller providers with low email volumes, > are put in the spam folder, even if they never send spam, just because their > email volume is so low (ergo, they must prove they don't spam before getting > out of ispam folder) OP is trying to come up with a solution to handle transactional email within members of the office and some vendors/clients, not bulk email like you're describing. As for "costs money", well everything in life does. You can't get a branch office's email system setup for free. > Another thing is that you cannot impose IP restrictions when using Google > Apps, or have SSO with trusted access from inside the office. (for example - > scan your badge at the office door, your personal computer is automatically > logged on and you get access to everything). Eh, sure -- I suppose if the country you're operating in doesn't have open communications with google ( https://transparencyreport.google.com/traffic/overview ) then yeah, you're gonna have a hard time. But this seems like a stretch for an argument against using a hosting provider. > With locally hosted servers, of course you have to keep them updated. Most > linux distributions can keep them updated automatically. My question was directed at OP as it sounded like they were coming in to set something up once then moving on in life. I wouldn't say that _any_ major linux distro updates automatically. Rolling OS distros like arch are constantly getting wedged and requiring a bit of manual attention to nudge things along. Distros like fedora can sorta kinda run with a `dnf upgrade` happening in a cron if you like to... I guess. Maybe something like RHEL can be set and forgotten, but if you're paying for a RHEL license then you're likely not going to abandon the host.
Re: Looking for a guide to collect all e-mail from the ISP mail server
At 25 October, 2020 R. Diez wrote: > > I am too afraid, I would not expose any such port on the Internet. Who knows > if the mail server stays months without an update. If I am to recommend or > implement any such mail server solution to a small business, I would insist > that the e-mail server is not exposed at all on the Internet. Setting and forgetting any server/service to run unpatched for months is generally a bad idea. I presume that you won't be maintaining this for them long term -- why not just point them at a hosting service like google apps, and let google keep things up to date?
Re: Looking for a guide to collect all e-mail from the ISP mail server
Hello R, reply inline below: Am 25.10.20 um 23:12 schrieb R. Diez: That way your users can create their vacancies with the ISP portal, > [...] That's a good idea. But then internal e-mails need to go out to the ISP, don't they? Because, if internal e-mails get delivered locally, the vacation autoresponses on the ISP will not trigger, will they? The trouble is, with that configuration, if the Internet link goes down, internal e-mail stops working too. Hello R, I only wrote about the incoming side - of course, you also want to send mail to remote users, and that includes users with an address of …@myisp.com. They will go to the ISP and be fetched to local from there. And if internet's down, e-mail will stop working anyways, so why bother? Even facebook/whatsupp will stop working then! With some tinkering, you can configure your local relay smtp to deliver those locally, but if your people do not talk about their vacancies over the water cooler, then they will miss that reminder then. I was hoping that there would be a complete mail server setup guide somewhere for this kind of setup. But I guess I'll have to piece all these information snippets together. Sorry, the world is too big :) -- peter
Re: Looking for a guide to collect all e-mail from the ISP mail server
Hello R,
Your goal does not sound weird. The most painless way might be to fetch
incoming messages from the ISP's IMAP and deliver them to your local
dovecot. A shortened fetchmailrc would read:
poll remote.server …
user …, password …
folder 'INBOX'
fetchall
idle
ssl
mda "HOME=%T /usr/bin/sudo -u %T /usr/lib/dovecot/deliver"
That way your users can create their vacancies with the ISP portal, the
ISP will do availability, antivirus etc. You can even use sieve on
delivery. Perhaps fetch "Spam" too, if your ISP files it away.
Beware, you have to somehow keep tabs on remote and local usernames.
Passwords will be different. Local updates should be no problem with a
reasonable distro, e.g. the dovecot public repo.
Happy becoming a mail server admin!
Peter
Am 25.10.20 um 18:56 schrieb R. Diez:
Hi all:
I am evaluating mail server solutions for a small business. The trouble
is, I am only a part-time admin and a newbie to mail servers.
Most guides I have seen are rather unrealistic: they encourage you to
expose your e-mail server to the Internet, and hope that you have the
resources to keep it patched up.
I would rather have an internal mail server that collects e-mails from a
standard ISP mail server. It is like the old "POP3 Connector" that came
with Microsoft Exchange. Sometimes, there is a mailbox per user on the
ISP, and a corresponding one on the local server. Other times, there is
a single "catch all" or "multidrop" mailbox on the ISP.
Users can still access their internal mailboxes from outside through an
OpenVPN connection. The goal is that only VPN, and perhaps SSH, are
accessible from the outside. We do not need to arrange any special SMTP
configuration with the ISP either.
This kind of mail server setup is rather different to the standard
configuration. You do not normally need you own antivirus and spam
filter, and you do not need to configure SSL certificates, MX or SPF DNS
records. Most ISP handle that correctly and economically. Internal
e-mail does not leave your LAN, and your internal SMTP server is just a
relay for the external ISP SMTP server.
Furthermore, most guides do not explain how to setup an autoresponder
("I am on holiday until xxx") so that users can enable theirs with the
mouse. Editing configuration files over SSH is not really an option for
normal users. This detail is important because it could be the only
thing I need above standard e-mail. Further groupware features can be
seen as nice but ultimately unnecessary luxury, and a basic shared
calendar can be accomplished with a separate server like
https://radicale.org/ and a calendar client like one built into
Thunderbird. Hopefully, that is all I would need for a small business.
Can anyone point me to the kind of guide I need? Failing that, I would
need information or examples about using fetchmail, getmail or similar
software with Dovecot. Good or bad experiences from you guys would also
help.
Each of those tools has a detailed man page, but there are many options
and ways with different advantages and disadvantages. I would need a
simpler guide to get started.
I am aware that there are pre-packaged mail server solutions that would
perhaps bring an easy-to-use autoresponder, but I haven't seen one yet
that where you could tick a box like "this server is only internal and
collects mail from the ISP server" during installation. Nor have I seen
instructions about reconfiguring the mail server for my ISP mail scenario.
I am prepared to learn more and write my own Perl scripts and/or
installation guide, but it would be stupid to waste time if something
easy already exists. After all, the setup I am describing (external ISP
mail server + internal mail server) is not so weird.
Thanks in advance,
rdiez
Re: v2.3.11.3 solr plugin search via MUA fails to match accented ascii characters; cmd line exec of `doveadm fts lookup` PANICs (assertion failed)
Am 19.10.20 um 18:50 schrieb PGNet Dev: On 10/19/20 9:38 AM, Peter wrote: A network trace will show you, it TB actually requests something for your header search. Might be quicker that was my earlier quick-check ... abs nada from > tcpdump -i lo port 8984 on the server, when doing any -- header, body -- TBird search to the server PGNet, you should trace the IMAP stream. With TB perform (crlt-shift-F) a server-side-search (checkbox in the dialog) - even if encrypted, the number of packets alon shows if there is any traffic. A server side search should also take considerably longer, esp. when subfolders are in the mix. Here (quite current TB) headers will be searched only locally, box checked or not. -- peter
Re: v2.3.11.3 solr plugin search via MUA fails to match accented ascii characters; cmd line exec of `doveadm fts lookup` PANICs (assertion failed)
Am 19.10.20 um 18:17 schrieb PGNet Dev: On 10/19/20 9:15 AM, Peter wrote: If I remember correctly, that is an issue with TB - it only does body serches serverside, regardless of what you request, there should be an entry in their bugzilla, I'm too lazy right now. this is a very old bug at the very least, there are/were _known_ issues with TBird's search-on-server bits. now, whether that issue is still relevant here, I dunno yet; haven't finished digging through the ~ decade of Mozilla bug reports, finger pointing, and lack-of-resource complaints. grumble. A network trace will show you, it TB actually requests something for your header search. Might be quicker I would be surprised if that had been fixed in the meantime. I just configured solr to index from/to/subject headers together with body - one index is enough for my searching ;) -- peter
Re: v2.3.11.3 solr plugin search via MUA fails to match accented ascii characters; cmd line exec of `doveadm fts lookup` PANICs (assertion failed)
Am 19.10.20 um 17:00 schrieb PGNet Dev: search in TBird subject: aausdfrhyetdwgyatrdf => FOUND body: aausdfrhyétdwgyatrdf => FOUND subject: aausdfrhyetdwgyatrdf => FOUND body: aausdfrhyétdwgyatrdf => (emtpy) on header search, I'm _not_ seeing any additional activity in solr.log If I remember correctly, that is an issue with TB - it only does body serches serverside, regardless of what you request, there should be an entry in their bugzilla, I'm too lazy right now. -- peter
Leaked files in maildir "tmp" after vsz_limit crashes
Hi, Lately I've seen a few examples of users hitting the vsz_limit (usually trying to "delete" mails i Spam/Junk by moving them to Trash with a large dovecot.index.cache - which resulted in mails left/leaked in the tmp directory of Trash. Sometimes it seems the client gets into a state were it repeatedly tried to sync the client and server state so it does it again and again, building up the number of files/links in tmp. It seems the default 1 week interval to "unlink_old_files()" is not enough to prevent this from blowing up inode wise. However, ... lowering it, - or increasing vsz_limit feels a bit like kicking the can down the road. PS: This on dovecot 2.2.36 /Peter
Re: 2.3.11.3 on 32bit platforms
On 22/08/20 6:28 pm, Aki Tuomi wrote: The fix is pending in our review queue, but please find it attached. It'll be in master soon. I can confirm that these patches do indeed fix the problem for me. Thanks, Peter Ajamian
Re: 2.3.11.3 on 32bit platforms
On 18/08/20 2:15 pm, Peter wrote: I'm getting the same issue on a CentOS 6 i386 build: test-mech.c:371: Assert(#1) failed: strcmp(test_case->username,username) "testuser" != NULL test-mech.c:380: Assert(#1) failed: request->failed == FALSE auth mech APOP 2/84 .. : FAILED Full log of tests is at https://paste.centos.org/view/33771454 Any idea on this one? Peter
Re: RHEL7/CentOS7 RPM of dovecot 2.3.11.3-3 seems to have dropped tcpwrap support
On 22/08/20 2:45 am, Gerald Galster wrote: So is el8 truly incompatible with tcpwrap? Or is it just too much effort to continue suport for every feature that was ever in the system? https://access.redhat.com/solutions/3906701 "The TCP Wrappers package has been deprecated in RHEL 7 and therefore it will not be available in RHEL 8 or later RHEL releases". I should note that if there is enough demand for it I can look into building tcp_wrappers myself and supporting it for el8 in ghettoforge (as well as compiling dovecot against it). If the former, might it be reasonable for a user to change the 8's in the code below to 9's? I think you may be misunderstanding the boolean logic there, the code works as intended. Peter
Re: RHEL7/CentOS7 RPM of dovecot 2.3.11.3-3 seems to have dropped tcpwrap support
On 21/08/20 5:55 pm, Aki Tuomi wrote:
At a guess it was removed from the spec for el8 (which does not support
tcpwrap) and somehow got removed from el7 by accident. The ghettoforge
dovecot23 packages have tcpwrap support for el7:
We are looking into this, it was indeed removed from el7 by accident. RPM
macros can be quite tricky sometimes.
I have:
%if 0%{?rhel} < 8
BuildRequires: tcp_wrappers-devel
%endif
... then later ...
%if 0%{?rhel} < 8
--with-libwrap \
%endif
Peter
Re: RHEL7/CentOS7 RPM of dovecot 2.3.11.3-3 seems to have dropped tcpwrap support
On 20/08/20 11:02 pm, Thomas Scheunemann wrote: Using the Repo http://repo.dovecot.org/ce-2.3-latest after upgrading from 2.3.10.1-3 to 2.3.11.3-3 we get numerous error messages like: dovecot: imap-login: Error: connect(tcpwrap) failed: No such file or directory We use tcpwrap support in dovecot, which worked flawlessly in the older version. I can see that the socket /var/run/dovecot/login/tcpwrap is not created anymore. And comparing with RPMs, the new one seems to be missing the file: /usr/libexec/dovecot/tcpwrap which leads me to conclusion that the new version is just not compiled with tcpwrap support. At a guess it was removed from the spec for el8 (which does not support tcpwrap) and somehow got removed from el7 by accident. The ghettoforge dovecot23 packages have tcpwrap support for el7: # rpm -qf /usr/libexec/dovecot/tcpwrap dovecot23-2.3.11.3-1.gf.el7.x86_64 Peter
Re: 2.3.11.3 on 32bit platforms
On 13/08/20 9:16 pm, Michael Ströder wrote: On 8/13/20 10:56 AM, Aki Tuomi wrote: On 13/08/2020 11:31 Michael Ströder wrote: I'm trying to update openSUSE package on OBS [1] which builds for various OS versions and hardware platforms. To me it seems that a test fails on 32bit platforms: Excerpt of failed test: [ 576s] test-mech.c:370: Assert(#1) failed: strcmp(test_case->username,username) [ 576s] "testuser" != NULL [ 576s] test-mech.c:380: Assert(#1) failed: request->failed == FALSE [ 576s] auth mech APOP 2/84 .. : FAILED I'm getting the same issue on a CentOS 6 i386 build: test-mech.c:371: Assert(#1) failed: strcmp(test_case->username,username) "testuser" != NULL test-mech.c:380: Assert(#1) failed: request->failed == FALSE auth mech APOP 2/84 .. : FAILED Full log of tests is at https://paste.centos.org/view/33771454 Peter
Re: Tests failing on CentOS 6
On 17/08/20 9:17 pm, Timo Sirainen wrote: Looks like it's a gcc bug. It's not initializing the end_of_lines field in the unit test. Since it's in the unit test only, it's not harmful. Of course, the same gcc bug could be hitting some important places in the code.. but that's not a new issue. Only this unit test is really new and exposing this issue. i wasn't sure if it was the test that was the issue or the code that it was testing which is why I'm reluctant to disable the unit tests unless I have to. The problem goes away with: Thanks for the patch, it does indeed fix the issue at hand. I suppose the other way to deal with this might be to use gcc from devtoolset 9, but I prefer to stick with the CentOS stock GCC if at all possible. Now I'm getting a different failure when building the i386 packages which was already reported by someone else. I will follow up on this one in that thread. Peter
Tests failing on CentOS 6
Getting this when attempting to build 2.3.11.3 on CentOS 6: test-mail-cache.c:176: Assert failed: strcmp(str_c(str),"123\nfoo\n456\nbar\n") "" != "123 foo 456 bar " test-mail-cache.c:176: Assert failed: strcmp(str_c(str),"123\nfoo\n456\nbar\n") "" != "123 foo 456 bar " mail cache uncommitted lookups ... : FAILED Full make check output is at https://paste.centos.org/view/b48d38a9 I can provide full build logs if you want, but that's a 4M file so I'll provide it upon request. For now I'm going ot have to bypass the make check stage of the build for CentOS 6, but I worry that the failed check could be indicative of something critical. Peter
Re: Pigeonhole 0.5.11 released
On 13/08/20 9:16 am, Aki Tuomi wrote: Sorry about this, it was a s silly mistake when updating the version number. Not sure why our own build system didn't spot this when making 2.3.11-ce release... We'll see if there is a way to spot this kind of error in future, and of course we will do our best to ensure this won't happen again. Would it fix your build systems if we simply rename the file? As K. C. pointed out, it doesn't because the files still unpack into the wrong directory. I've managed to work around it for now with a tweak to the spec file, though. Peter
Re: Pigeonhole 0.5.11 released
On 13/08/20 7:48 am, Helmut K. C. Tessarek wrote: On 2020-08-12 09:02, Aki Tuomi wrote: We are pleased to release pigeonhole 0.5.11. You can download it from locations below: https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3.11-pigeonhole-0.5.11.tar.gz https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3.11-pigeonhole-0.5.11.tar.gz.sig Unfortunately you broke all build systems (rpm, deb, ...) with that release name. .11 should have neve been included in the name. As you can see from previous releases the dovecot patch number was never in the pigeonhole tarball release name. Yes, please fix in future releases. I already have to define the 2.3 separately from the 11.3 in my spec file, with this change I either have to rename the file or have three definitions: 2.3, 11 and 3 (I renamed the file). Peter
Deliver administrative message ignoring user quota
Hi everyone, I have a separate internal system running on a different host that needs to put an administrative email into a user’s inbox. I’ve been playing around with the “doveadm mailbox save” command via Doveadm’s HTTP API (https://doc.dovecot.org/admin_manual/doveadm_http_api/#doveadm-mailbox-save <https://doc.dovecot.org/admin_manual/doveadm_http_api/#doveadm-mailbox-save>). This works quite well provided the user is within quota limit, however, I would like to be able to deliver these messages even if the email account is over quota. I noticed that it’s possible to override the quota configuration using dovecot-lda by overriding plugin/quota with the “noenforcing” directive as explained in https://wiki.dovecot.org/Quota/Configuration <https://wiki.dovecot.org/Quota/Configuration>. I don’t currently use LDA, SMTP servers based on Postfix deliver mail via LMTP and I need to be able to deliver this message from a different host in the network. The HTTP API doesn’t seem to support overriding the quota config. What would be the best way to go about this? Thanks Peter
Re: Packages for CentOS 8
On 2/06/20 5:18 am, Aki Tuomi wrote: Aki: If you're talking about quota-devel it has been available now from CentOS in the Devel repo for a while. If you're talking about tcp_wrappers-devel, that is not available and I don't think it ever will be because CentOS 8 has obsoleted tcp wrappers. I have simply disabled tcp wrappers functionality in my GhettoForge build. I'm not aware of any other missing dependencies. We are adding zstd compression support in 2.3.11, which was nicely broken by redhat/centos in 8.1, and will be fixed in 8.2. That makes sense. At the moment 2.3.10.1 is packaged in GhettoForge, and in that case I may just have to wait until 8.2 drops to release 2.3.11, or if I can selectively disable zstd in the build I can do that until 8.2 drops and then rebuild. Peter
Re: Packages for CentOS 8
On 2/06/20 1:49 am, Aki Tuomi wrote: we are still waiting for CentOS 8 Repo for current Dovecot version from here https://repo.dovecot.org/. Do you have an idea when it will come? Who does it maintain? Is it the Dovecot team? Thanks, Tobias Yes, it's maintained by us. We are working on it and hopefully we are able to publish next release for CentOS8. There are unfortunately some package dependency issues which are not yet fixed in CentOS8, so let's hope those are fixed before we do our release. Aki: If you're talking about quota-devel it has been available now from CentOS in the Devel repo for a while. If you're talking about tcp_wrappers-devel, that is not available and I don't think it ever will be because CentOS 8 has obsoleted tcp wrappers. I have simply disabled tcp wrappers functionality in my GhettoForge build. I'm not aware of any other missing dependencies. Tobias: You are more than welcome to use the packages from GhettoForge which are now in the gf-plus repo. I would love to hear feedback if you have any issues with them. Peter
Re: identify 143 vs 993 clients
On 31/05/20 6:50 pm, Jean-Daniel wrote: Yes and no. Some of the attack vectors mentioned are not reasonable and it really depends on the client. Thunderbird, for example, used to have settings for plain text, TLS and "TLS if available", but the latter setting has not been available for some time which forces the user to choose either plain text or TLS at setup time now. This means that the user would now have to change the setting in their client for a downgrade attack to work. I can't speak for all MUAs but if they similarly have removed their "TLS if available" option or if the users explicitly don't pick that option (you can ask them not to in your setup instructions) then that type of downgrade attack cannot occur. The other possible downgrade attack which was not mentioned but is equally mitigated by the client is where the MITM intercepts the connection, connects to your server and issues a STARTTLS itself but presents the resulting connection as plain text to the client. This means that enforcing STARTTLS on the server side will not prevent a plain text connection through a MITM from the client. But do keep in mind that if the client is configured properly to only connect via TLS then it will refuse the connection if it is not presented with a STARTTLS option that works. So yes the safest way to go is to just use port 993, but as long as the client is not set to a "TLS if available" option then port 143 is also safe. I don’t think you can call an option safe if it relies on the users to properly configure their client. We all know that users are usually bad at following instructions ;-) Fair enough, but this attack vector can only happen if it's on a client that supports a downgrade option (I should hope that most don't nowadays, but someone did mention MacOX Mail earlier) *and* the user selects that option when configuring as opposed to the stricter "TLS only" (or equivalent) option. At that point it still requires a MITM attack to downgrade the connection, and that MITM must not only be able to read the packets but also intercept them and present different data to the user. I can see this type of attack happening in wifi environments and coming from ISPs that want to snoop on people's email, though. As I said (and I stand by it) the safest approach is to just limit to port 993, but port 143 is also safe if properly configured on both the server and client side. Peter
Re: identify 143 vs 993 clients
On 29/05/20 11:27 pm, mj wrote: Thanks to all who participated in the interesting discussion. It seems my initial thought might have been best after all, and discontinuing port 143 might be the safest way proceed. Yes and no. Some of the attack vectors mentioned are not reasonable and it really depends on the client. Thunderbird, for example, used to have settings for plain text, TLS and "TLS if available", but the latter setting has not been available for some time which forces the user to choose either plain text or TLS at setup time now. This means that the user would now have to change the setting in their client for a downgrade attack to work. I can't speak for all MUAs but if they similarly have removed their "TLS if available" option or if the users explicitly don't pick that option (you can ask them not to in your setup instructions) then that type of downgrade attack cannot occur. The other possible downgrade attack which was not mentioned but is equally mitigated by the client is where the MITM intercepts the connection, connects to your server and issues a STARTTLS itself but presents the resulting connection as plain text to the client. This means that enforcing STARTTLS on the server side will not prevent a plain text connection through a MITM from the client. But do keep in mind that if the client is configured properly to only connect via TLS then it will refuse the connection if it is not presented with a STARTTLS option that works. So yes the safest way to go is to just use port 993, but as long as the client is not set to a "TLS if available" option then port 143 is also safe. Also note that the same concerns apply for your submission server (likely postfix) using the submission port (587) and enforcing STARTTLS vs the submissions port (465) which is a direct TLS connection. Peter
Re: child killed by signal 6
Hi Stephan,
the "panic output" in dovecot.log is:
Nov 01 11:54:14 master: Warning: Killed with signal 15 (by pid=18477
uid=0 code=kill)
Nov 01 11:54:44
lda(peter.nabbef...@gmx.de)<18496>: Panic: file
istream-crlf.c: line 24 (i_stream_crlf_read_common): assertion failed:
(ret != -2)
Nov 01 11:54:44
lda(peter.nabbef...@gmx.de)<18496>: Error: Raw
backtrace: /usr/lib/dovecot/libdovecot.so.0(+0xff784) [0x7f9d3382b784]
-> /usr/lib/dovecot/libdovecot.so.0(+0xff7c1) [0x7f9d3382b7c1] ->
/usr/lib/dovecot/libdovecot.so.0(+0x493aa) [0x7f9d337753aa] ->
/usr/lib/dovecot/libdovecot.so.0(+0x4bf62) [0x7f9d33777f62] ->
/usr/lib/dovecot/libdovecot.so.0(+0x111076) [0x7f9d3383d076] ->
/usr/lib/dovecot/libdovecot.so.0(i_stream_read_memarea+0x81)
[0x7f9d33839291] -> /usr/lib/dovecot/libdovecot.so.0(i_stream_read+0x37)
[0x7f9d33839477] -> /usr/lib/dovecot/libdovecot.so.0(+0x1164a8)
[0x7f9d338424a8] ->
/usr/lib/dovecot/libdovecot.so.0(i_stream_read_memarea+0x81)
[0x7f9d33839291] -> /usr/lib/dovecot/libdovecot.so.0(i_stream_read+0x37)
[0x7f9d33839477] ->
/usr/lib/dovecot/libdovecot.so.0(i_stream_read_data+0x4c)
[0x7f9d33839f3c] ->
/usr/lib/dovecot/libdovecot.so.0(io_stream_copy+0x8a) [0x7f9d33854bea]
-> /usr/lib/dovecot/libdovecot.so.0(+0x12aa86) [0x7f9d33856a86] ->
/usr/lib/dovecot/libdovecot.so.0(o_stream_send_istream+0x4f)
[0x7f9d3385486f] ->
/usr/lib/dovecot/libdovecot-storage.so.0(index_storage_save_continue+0x2e)
[0x7f9d339da14e] ->
/usr/lib/dovecot/libdovecot-storage.so.0(maildir_save_continue+0x27)
[0x7f9d33978be7] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mailbox_save_continue+0x47)
[0x7f9d3394a5b7] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mail_storage_copy+0xe8)
[0x7f9d3393b388] ->
/usr/lib/dovecot/libdovecot-storage.so.0(maildir_copy+0x6d)
[0x7f9d3397499d] -> /usr/lib/dovecot/libdovecot-lda.so.0(+0x3c46)
[0x7f9d33a6bc46] ->
/usr/lib/dovecot/modules/lib20_fts_plugin.so(+0x11004) [0x7f9d334b9004]
-> /usr/lib/dovecot/libdovecot-storage.so.0(+0x59b0c) [0x7f9d3394ab0c]
-> /usr/lib/dovecot/libdovecot-sieve.so.0(+0x4edb8) [0x7f9d311a9db8] ->
/usr/lib/dovecot/libdovecot-sieve.so.0(sieve_result_execute+0x54d)
[0x7f9d3119f5cd] -> /usr/lib/dovecot/libdovecot-sieve.so.0(+0x57a79)
[0x7f9d311b2a79] ->
/usr/lib/dovecot/libdovecot-sieve.so.0(sieve_multiscript_run+0xa9)
[0x7f9d311b3c49] ->
/usr/lib/dovecot/modules/lib90_sieve_plugin.so(+0x376b) [0x7f9d3122576b]
-> /usr/lib/dovecot/libdovecot-lda.so.0(mail_deliver+0x199) [0x7f9d33a6d6d9]
Kind regards
Peter
Am 25.05.20 um 21:12 schrieb Stephan Bosch:
On 25/05/2020 12:06, Aki Tuomi wrote:
On 25/05/2020 13:00 Peter Nabbefeld wrote:
Hello,
from time to time I keep getting problems with some emails causing
signal 6. I've already reported those, but it seems not to be easy to
find the cause. From the logs, it seems to occur in sieve
implementation.
I've checked the email envelopes tody by accident, probably this
part of
my telnet session might help:
a11 fetch 1 all
* 1 FETCH (RFC822.SIZE 16750 INTERNALDATE "22-May-2020 05:02:34 +"
ENVELOPE ("Fri, 22 May 2020 03:46:54 +" "RE: Http2 tomact server
taking time in responding when 1st StreamId is a large integer value
like 2147483641" (("Prateek Kohli" NIL "prateek.kohli"
"ericsson.com.INVALID")) (("Prateek Kohli" NIL "prateek.kohli"
"ericsson.com.INVALID")) (("Tomcat Users List" NIL "users"
"tomcat.apache.org")) (("Tomcat Users List" NIL "users"
"tomcat.apache.org")) NIL NIL
"""
")
FLAGS (\Seen))
a11 OK FETCH completed
a12 fetch 2 all
* 2 FETCH (RFC822.SIZE 21146 INTERNALDATE "22-May-2020 06:39:54 +"
ENVELOPE ("Fri, 22 May 2020 06:39:35 +" "RE: RST on TCP level sent
by Tomcat" (("Arshiya Shariff" NIL "arshiya.shariff"
"ericsson.com.INVALID")) (("Arshiya Shariff" NIL "arshiya.shariff"
"ericsson.com.INVALID")) (("Tomcat Users List" NIL "users"
"tomcat.apache.org")) (("Tomcat Users List" NIL "users"
"tomcat.apache.org")) (("ma...@apache.org" NIL "markt" "apache.org")("M
Venkata Pratap M" NIL "m.m.venkata.pratap" "ericsson.com")) NIL "
"
"
")
FLAGS ())
a12 OK FETCH completed
The first message causes signal 6, the second does not. Probably the
problem is killed by the two consecutive "NIL"s? I'm not an experienced
administrator, only managing my private computer, so I don't know the
meaning of every envelope field. But might these two "NIL"s cause
the abort?
BTW, to download all messages from my IMAP account to my private
dovecot
instance I had to delete the first message, since I couldn't download
any other messages from the IMAP folder otherwise.
Kind regards
Peter
Hi!
Can you provide the original mail? Optionally processed via
https://dovecot.org/tools/maildir-obfuscate.pl ?
Also, can you provide 'doveconf -n' output?
There is usually some panic message in the logs. We need that as well.
Regards,
Stephan.
