Re: dovecot TSL 1.3 config option 'ssl_ciphersuites' causes fatal error on launch. not supported, bad config, or bug?
Citeren PGNet Dev : I've installed grep PRETTY /etc/os-release PRETTY_NAME="Fedora 32 (Server Edition)" dovecot --version 2.3.10.1 (a3d0e1171) openssl version OpenSSL 1.1.1g FIPS 21 Apr 2020 iiuc, Dovecot has apparently had support for setting TLS 1.3 ciphersuites since v2.3.9, per this commit lib-ssl-iostream: Support TLSv1.3 ciphersuites https://github.com/dovecot/core/commit/8f6f04eb21276f28b81695dd0d3df57c7b8f43e4 There is a pull request for TLSv1.3 sitting in the queue: https://github.com/dovecot/core/pull/126, maybe this helps?
Re: doveadm SSL problem with recent update
Citeren "Trever L. Adams" : With a recent update, I started seeing this: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 14: ssl_cert: Can't open file /etc/letsencrypt/live/SERVER/fullchain.pem: Permission denied 1 4 * * * vmail /usr/bin/doveadm expunge -A mailbox MAILBOXINQUESTION savedbefore 1w is one of the crontab entries I am seeing this for. Is there an option to keep doveadm from trying to use the ssl cert from that configuration file? I do not want to have the vmail user having access to the pem cert. Rename your existing 10-ssl.conf to 10-ssl.conf.ext and make it readable by root only. Now create a new 10-ssl.conf file with the following content: # SSL/TLS support: yes, no, required. ssl = no !include_try 10-ssl.conf.ext This will cause all non-root users to disable SSL and will only enable it when started as root.
Re: SV: SV: Looking for a guide to collect all e-mail from the ISP mail server
Citeren Sebastian Nielsen : Because when I email to friends that are using gmail, my mail ends up in spam unless my friends put me in whitelist. Seems to vary however, and seems to get better with time. In order to prevent ending up in spam in GMail, it is necessary to have working DKIM and/or SPF for your messages and forward- and reverse DNS records for your mailserver match.
Re: SSL alert number 42
Citeren Raymond Herrera : That is good to know. I was working on the wrong assumption, attempting to create a client certificate on the Windows/Thunderbird side. I am using the SSL Certificate that comes with the distribution, so the conclusion is Thunderbird does not trust it. I have this in my notes from ages ago, for generating my own self-signed certificate: % openssl req -x509 -newkey rsa:4096 -sha256 -keyout openssl.key -out openssl.crt -days 600 -config san.cnf See attached the 2 errors that I am getting, one is from the distribution cert. I recommend you stay clear of self-signed certificates if the number of users is greater than one, unless there is a very specific need to use them. Setting up multiple systems to trust your self-signed certificate is no fun when you need to aid people in setting up their systems to trust it. Can a kind soul tell me the current way to do this in Linux? Perhaps I should use a free service? Which? In most cases, Letsencrypt will work just fine. Do remember to setup auto renewal for your certificate(s) and make sure you trigger your systems to reload them upon renewal. You wouldn't be the first to forget about the latter. TIA Raymond
Re: t/s expired cert error
Citeren Voytek Eymont : On Wed, March 3, 2021 1:17 am, Yassine Chaouche wrote: hmm, just tried this, 110/143 gives error, 995/993 doesn't: I'll try changing in TB to SSL/TLS not StartTLS, 995 or 993, etc, and, see if error goes # echo | openssl s_client -connect emu.sbt.net.au:110 2>/dev/null | openssl x509 -noout -enddate On port 110/143 you need to tell the POP3/IMAP server to upgrade the connection to TLS. In that case, it will work just fine: # echo | openssl s_client -connect emu.sbt.net.au:110 -starttls pop3 2>/dev/null | openssl x509 -noout -enddate notAfter=Apr 27 12:11:32 2021 GMT #echo | openssl s_client -connect emu.sbt.net.au:143 -starttls imap 2>/dev/null | openssl x509 -noout -enddate notAfter=Apr 27 12:11:32 2021 GMT Remember that there is a difference between connections that are upgraded to TLS (110/143) and connections that use SSL by default (995/993). If you don't tell the first that you want to use TLS, the server will not present the certificate, unlike the latter. Regards, Arjen
Re: How to prevent, or change priority, of dovecot's FAILed relay-submission to relay's IPv6 address, and submit ONLY/first to IPv4?
Citeren PGNet Dev : On 4/9/21 8:08 AM, @lbutlr wrote: On 08 Apr 2021, at 06:08, PGNet Dev wrote: whereas other services listen at both IPv4 & IPv6 addresses, with IPv6 preferred over IPv4, postfix listens ONLY on IPv4, Do you mean that YOUR postfix only listens to ipv4? Yep. If so, wouldn't the solution be to setup postfix to listen to ipv6? That would work, of course, but that's not the point. I'm not planning to open postfix listener on the public IPv6 in order to accommodate one service connection (Dovecot's relay submit), only to have to add add'l knobs to lock down access. There is no need to use a global address, assuming the systems Postfix and Dovecot are on the same LAN, a link-local IPv6 address would be just fine. This is no less insecure than a RFC1918 IPv4 address. And it's a bad assumption that since the host is dual-stack that all services on it will be. I fail to see why. If a hostname resolves to both an A and record, it should provides services on both. The 'solution' is to have Dovecot relay submit connect where & how you TELL it to connect, NOT where it assumes it's OK to connect. You've already told it where to connect: internal.mx.example.com. Since that host has both an A and record, you're telling it both are equally fine. If that's not what you want, either hardcode the IPv4 address in the submission_relay_host or create an internal-ipv4.mx.example.com A record. It's already possible to set submission_relay_host = submission_relay_port = submission_relay_ssl= submission_relay_ssl_verify = submission_relay_trusted= in order to specify exactly how/where to securely connect for relay. It's a head scratcher what the philosophical reticence is for completing the picture with a submission_relay_inet_protocols or somesuch. It's a head scratcher why people still insist on running services on legacy IPv4 only.
Re: What imap ssl/auth settings work best with MS Outlook?
Citeren "@lbutlr" : When you enter your email address, it would be TRIVIAL to check the MX records for the domain and fill those in for the SMTP and IMAP servers, allowing users to more easily add (if needed) the domain prefix. No one does this. Rightfully so. There is absolutely no guarantee that the server on the inbound (MX) record also handles outbound and/or IMAP. In many cases, these will be different systems.
Re: What imap ssl/auth settings work best with MS Outlook?
Citeren "@lbutlr" : On 30 Apr 2021, at 01:20, Arjen de Korte wrote: Citeren "@lbutlr" : When you enter your email address, it would be TRIVIAL to check the MX records for the domain and fill those in for the SMTP and IMAP servers, allowing users to more easily add (if needed) the domain prefix. No one does this. Rightfully so. There is absolutely no guarantee that the server on the inbound (MX) record also handles outbound and/or IMAP. In many cases, these will be different systems. It is very very common. It's been at least a decade since I saw a configuration in which the SMTP/IMAP servers were on a different domain than the MX domain. It´s getting less and less common. I see plenty domains where e-mail spam/virus protection is outsourced and where there is absolutely no hope of guessing the correct hostnames for outbound or IMAP servers based on the domain of the MX record. Configuring Autodiscover records may help somewhat, but even then YMMV.
Re: Sieve daemon errors? (Part 1 of 2, Pt 2 to follow when Pt 1 resolved)
Citeren Dan Egli : Still haven't heard back on why 4190 isn't being listened to. I put the entire /etc/dovecot/conf.d directory into https://www.newideatest.site/dovecot, so feel free to look at the configs and see if you can figure out why the sieve listener isn't running. You messed up your 20-managesieve.conf. You should only have to follow the below instruction to get the sieve listener running: # Uncomment to enable managesieve protocol: #protocols = $protocols sieve So restore the original (it looks like it is in 20-managesieve.conf.ucf-dist) an just uncomment the one line that is mentioned above so that it reads # Uncomment to enable managesieve protocol: protocols = $protocols sieve
Re: move mails between mailboxes
Citeren Tom Doenen : Hello, i am using dovecot 2.3.4.1 I am tyring to make a script using the doveadm move command to move old emails into a subfolder of the users INBOX ; say all mails from 2016 into INBOX/2016. Selecting and moving is not the issue; everything works just i am amazed that the (test) mail client Thunderbird downloads all mails in INBOX/2016 after the move. When i make an IMAP move of all 2016-mails in Thunderbird; mails are moved between the mailboxes without any mails being (re-)downloaded. So what am i missing here? That's because in that case Thunderbird will know that the mails are moved between the mailboxes and will tell the server to move the messages and then do the move locally (without downloading the messages again). If you do this on the server, the client has no idea these are the same mesasages and will procede to delete them from the original location and download them again from the new location. The same happens if you move them in Thunderbird on one device and you have a second device. Even if it also uses Thunderbird, it will have to download them again.
Re: Strategies for protecting IMAP (e.g. MFA)
Citeren Benny Pedersen :
On 2021-11-14 20:26, Matthew Richardson wrote:
On Sun, 14 Nov 2021 08:12:53 -0800, Michael Peddemors wrote:-
And there are RBL's now for know IP(s) used by IMAP hackers, including
SpamRats RATS-AUTH that can assist in reducing those attacks.
Looking at https://www.spamrats.com/rats-auth.php the "Example Usage in
Dovecot" says "PLEASE UPDATE".
How would one use a DNSBL like this in Dovecot to reject IMAP connections
from listed IPs?
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_delay_reject=no
-o { smtpd_client_restrictions = reject_rbl_client
auth.spamrats.com=127.0.0.39, permit }
-o { smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject }
This is not an answer to the question, this is Postfix syntax.
openRelay, dont do it
In what way would this create an open relay exactly? The 'permit' at
the end of the 'smtpd_client_restrictions' only means that the client
is accepted, not that other smtpd restrictions are lifted.
resolved version
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_delay_reject=no
-o { smtpd_relay_restrictions = reject_rbl_client
auth.spamrats.com=127.0.0.39, permit_mynetworks,
permit_sasl_authenticated, reject }
Although syntactically correct, it is confusing at best to put client
restrictions in another place than smtpd_client_restrictions.
Especially with 'smtpd_delay_reject=no' in effect you'd only reject
after receiving 'RCPT TO', which is evaluated after
'smtpd_client_restrictions' and 'smtpd_helo_restrictions' during the
SMTP transfer.
order do matter
Indeed.
Mailinglistserver IPv6 address blacklisted
It looks like the mailinglist server IPv6 address has been blacklisted: https://check.spamhaus.org/listed/?searchterm=2a04:3545:1000:720:acc1:5bff:fe5e:459 The 'Show details' shows the entire 2a04:3545:1000:720::/64 network is blacklisted. Whois tells this is a network used by UpCloud Cloud Servers. So either the mailinglistserver or a server it shares its network with is compromised. If UpCloud gives its users their own /64, it would probably be the former. Otherwise it might make sense to ask them for one, as sharing IPv6 networks between customers is a no-no in the IPv6 world.
Re: source code doesn't compile
Citeren Ruben Safir : Its not older than stretch. It is based on opensuse -- how could it behvave so differently with regard to auth As the maintainer of a couple of openSUSE packages (not Dovecot though), may I ask which openSUSE version it was based off? So that we can get an idea of what we're looking at in terms of versions of packages installed. Anything older than 12.2 is probably going to be a lot of work, as that was the first one that shipped openssl >= 1.01.
Re: how to setup dovecot to accept client certificates signed with a private CA when the server certificate is signed by a public CA
Citeren jean-christophe manciot : Hi everyone, I'm trying to setup dovecot to accept only client certificates created with a private CA: auth_ssl_require_client_cert = yes ssl_verify_client_cert = yes ssl_ca = This is wrong, you should enter your private CA here. If 'ssl_verify_client_cert' is not set to 'yes', this field should generally be empty / not configured. At the same time, dovecot is setup with an SSL certificate created by a public CA (let's encrypt): ssl = required ssl_cert = As you probably already know, let's encrypt does not create client certificates. It seems that using a different CA for client certificates and for the server certificate is unsupported. Am I missing something?
Doveadm error since 2.3.11.3 when run as unprivileged user
I allow users to run 'doveadm' for mailbox maintenance (to expunge mail for instance). Since the upgrade to 2.3.11.3, this no longer works and results in the following error message: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 13: ssl_key: Can't open file /etc/ssl/private/de-korte.org.key: Permission denied This is no surprise, as non-privileged users are not allowed to read the private keys of the server. Question is, why is doveadm trying to read this key in the first place (it is not needed for mailbox maintenance) and why is it failing now? Regards, Arjen
Re: Doveadm error since 2.3.11.3 when run as unprivileged user
Citeren Timo Sirainen : On 13. Aug 2020, at 11.29, Timo Sirainen wrote: On 13. Aug 2020, at 11.00, Arjen de Korte wrote: I allow users to run 'doveadm' for mailbox maintenance (to expunge mail for instance). Since the upgrade to 2.3.11.3, this no longer works and results in the following error message: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 13: ssl_key: Can't open file /etc/ssl/private/de-korte.org.key: Permission denied This is no surprise, as non-privileged users are not allowed to read the private keys of the server. Question is, why is doveadm trying to read this key in the first place (it is not needed for mailbox maintenance) and why is it failing now? There were some ssl setting handling cleanups in v2.3.11, which caused this. I guess the proper fix for this would be to split SSL client settings and SSL server settings. So doveadm would still read the SSL client settings without trying to read the SSL server settings and failing there. As a workaround, it should be possible to put the ssl_key into a separate config file and use !Include_try for it. For example in dovecot.conf: !include_try ssl-keys.conf That will only work to include an optional configuration file and suppress errors if it doesn't exist. I put ssl_key = in a separate configuration file and it failed in a similar fashion, just with another filename.
Re: Doveadm error since 2.3.11.3 when run as unprivileged user
Citeren Josef 'Jeff' Sipek : On Thu, Aug 13, 2020 at 21:16:42 +0200, Arjen de Korte wrote: Citeren Timo Sirainen : > !include_try ssl-keys.conf That will only work to include an optional configuration file and suppress errors if it doesn't exist. I put ssl_key = I think the idea was that the file with the ssl_key line was only root-readable. That way, non-privilged users will fail to include the file. Is that what you tried? No, but you put me on the right track. What is needed is to !include_try the whole previous SSL configuration file only for root and to precede this by an include for a new one which disables SSL completely. So first SSL will be disabled for all users (including root) and only for root, the SSL configuration will be loaded after that.
Re: doveadm/doveconf as user tries and fails to read host key
Citeren jimc : Distro: OpenSuSE Tumbleweed for x86_64 Failing version: dovecot23-2.3.11.3-1.1.x86_64 Install Date: 2020-08-18 Reverting to previous version works: dovecot23-2.3.10.1-2.3.x86_64 (Packages downgraded coordinately: dovecot23 dovecot23-backend-sqlite) How to make it fail: As the user, execute doveadm expunge mailbox Spam37 savedbefore 3day #User's actual cmd doveadm who #The simplest possible command, for testing It says: doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 12: ssl_cert: Can't open file /etc/ssl/hostcerts/hostw.cia: Permission denied This was mentioned before on this list. See https://dovecot.org/pipermail/dovecot/2020-August/119650.html how to solve this. The actual EPERM occurs trying to traverse a directory in /etc/letsencrypt, but the next configuration item to be read (in the SSL section) is the host's private key, and the user is surely not ever going to get permission to read that. (I did test giving the user permission to the 750 directory and it did attempt to read the private key, failing.) If you run it as root, of course it works because root has read permission. The initial failure was seen running as the user from cron. Behavior seen in strace: doveadm execs doveconf; doveconf reads the configuration and saves it somewhere (shared memory?); doveconf execs the next program which in this case is doveadm with its original command line; and doveadm now knows its configuration. I can re-do and post the strace if needed. I don't know why doveconf is reading the SSL keys in 2.3.11.3 when it didn't in 2.3.10.1, but if the idea is to read the complete configuration in case it might be needed in obscure situations, a possible workaround is to not die on unreadable secrets and to report those either as unset or as a new "error" symbol, letting the consumer (doveadm) deal with the fallout, or in this case ignore it. Attached: sysreport.gz ; doveconf-n.out Dovecot's working files and user mailboxes are on ext4 filesystems; NFS is not involved. The mail reader is Roundcube webmail.
Re: Dovecot mail-crypt webmail can't read encrypted messages
Citeren Serveria Support : Yes, there is a tiny problem letting the attacker change this value back to yes and instantly get access to users' passwords in plain text. Apart from that - no problems at all. :) If an attacker is able to modify your Dovecot configuration, you have bigger problems than leaking your users' password. Much bigger...
Re: Error: /proc/self/status is larger than expected
Citeren Elisamuel Resto Donate : [ snip ] It might help to check how large /proc/self/status is on your system: # cat /proc/self/status|wc --bytes Here it shows 1381 bytes.
Dovecot LTO build failure
In openSUSE Tumbleweed (and several other distributions as well), packages are build by default with linktime optimization (LTO) enabled. This didn´t work for Dovecot, so until now LTO was disabled for Dovecot. There is a way to make it work though, see the following link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997513#20 So far a fix has not made it to upstream, the latest version 2.3.30 still fails to build without this patch. Is there any news to report regarding this?
Re: Mailing list changes.
Citeren dovecot--- via dovecot : I noticed starting today the Sender: header is no longer included on the mailing list. I used to use the Sender: header in sieve rules for sorting. Now the list emails only come From: rando email addresses. On the postfix mailing list it replaces the From: header with the list address instead of keeping the original email author. Is this the future intended behavior? Or can we get a Sender: or From: header to contain the list address for sorting? Use the List-Id header instead: List-Id: Dovecot Mailing List ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: DOvecot requires both IPv4 and IPV6 to start
Citeren Shawn Heisey : An interesting read: https://cr.yp.to/djbdns/ipv6mess.html FUD. This document was written something like two decades ago and pretty much all arguments against IPv6 are no longer relevant anymore. In most cases nowadays, the user experience for IPv6 will be far superior over CGNAT connections which unfortunately become the standard due to the increasing cost of IPv4 addresses. Running services over IPv6 may have been experimental and prone with not so fun problems to diagnose in 2013, but today this is no longer the case. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Is XOAUTH2 support broken in 2.3.21?
Citeren Christian Rößner via dovecot : Hi, I use Roundcube with OIDC. Everything works fine in Dovecot 2.3.20, but broke in 2.3.21. Downgrading to 2.3.20 makes it work again, so it is introduced in the newer release. Error (2.3.21): ``` Oct 4 11:03:57 mx dovecot[558531]: imap-login: Disconnected: Connection closed (client didn't finish SASL auth, waited 1 secs): user=, orig_user=, method=XOAUTH2, rip=192.168.0.4, lip=192.168.0.2, TLS, TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) ``` Here is an example with 2.3.20: Success (2.3.20): ``` Oct 4 11:17:21 mx dovecot[889914]: imap-login: Login: user=, orig_user=, method=XOAUTH2, rip=192.168.0.4, lip=192.168.0.2, mpid=891874, TLS, TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) ``` Searching the archives might give a lead to what's going on (and a possible workaround): https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/RR2GXLOAS6U3MZCQCA4T4S6QXCRV5GST ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Managesieve "config" unable to complete?
Citeren joe a : Dovecot installed on OpenSuse Leap 15.5, from their supplied "dovecot23" package. That package claims to be Dovecot 2.3.21 and Pigeonhole 0.5.21 You need to change the following two files: /etc/dovecot/conf.d/20-managesieve.conf protocols = $protocols sieve /etc/dovecot/conf.d/20-lmtp.conf mail_plugins = $mail_plugins sieve With these changes, you should at least see that sieve is running. Note that if you're using AppArmor and depending on where you store users mail, you may need to tweak the profiles. In that case, 'aa-logprof' is your friend. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Managesieve "config" unable to complete?
Citeren joe a : On 1/23/2024 13:20:20, Arjen de Korte wrote: Citeren joe a : Dovecot installed on OpenSuse Leap 15.5, from their supplied "dovecot23" package. That package claims to be Dovecot 2.3.21 and Pigeonhole 0.5.21 You need to change the following two files: /etc/dovecot/conf.d/20-managesieve.conf protocols = $protocols sieve /etc/dovecot/conf.d/20-lmtp.conf mail_plugins = $mail_plugins sieve With these changes, you should at least see that sieve is running. Note that if you're using AppArmor and depending on where you store users mail, you may need to tweak the profiles. In that case, 'aa-logprof' is your friend. Thanks for the suggestions. Those conf settings were OK, "sieve" needed adding to dovecot.conf and not 20-managesieve.conf. In that case, you've probably messed up your configuration somehow. The line in 20-managesieve.conf mentioned above should add sieve to the list of protocols as it is included by the !include conf.d/*.conf near the end of /etc/dovecot/dovecot.conf. Should have tried that much earlier, but had convinced myself otherwise. In openSUSE you probably should never touch /etc/dovecot/dovecot.conf, as all settings are set in the /etc/dovecot/conf.d/*.conf files. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Bug/Warning not sure which
Citeren Markus Winkler : Also the time is important. Your wrote: on 2/22/24 or 2/23/24 it stopped working Have a look at the cert's validity: --> Not Before: Feb 22 14:45:49 2024 GMT All these details seems to be matching IMHO. That seems to be a coincidence. Looking at the history of certificates for the sgeinc.com domain, it is almost three years ago there was a valid certificate for mail.sgeinc.com: https://crt.sh/?q=sgeinc.com There doesn't seem to be a change in SAN since 2021-07-04. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
