dovecot and oauth2 (with keycloak) not working
Hi, I successfully configured Roundcube to use keycloak for oauth2. However, I am having trouble to make it work with dovecot. My configuration is this: cat dovecot-oauth2.conf.ext tokeninfo_url = https://auth.mydomain.com/realms/myrealm/protocol/openid-connect/userinfo introspection_url = https://auth.mydomain.com/realms/myrealm/protocol/openid-connect/token/introspect introspection_mode = post username_attribute = postfixMailAddress debug = yes scope = openid Roundcube_email This is what I am getting from the logs: Nov 20 08:20:30 auth: Error: ldap(fran...@mydomain.com,10.10.40.30,): ldap_bind() failed: Constraint violation Nov 20 08:20:30 auth: Debug: http-client: host auth.mydomain.com: Host created Nov 20 08:20:30 auth: Debug: http-client: host auth.mydomain.com: Host session created Nov 20 08:20:30 auth: Debug: http-client: host auth.mydomain.com: IPs have expired; need to refresh DNS lookup Nov 20 08:20:30 auth: Debug: http-client: host auth.mydomain.com: Performing asynchronous DNS lookup Nov 20 08:20:30 auth: Debug: http-client[1]: request [Req1: GET https://auth.mydomain.com/realms/med-lo/protocol/openid-connect/userinfoeyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJaYTFXcXhxb0RULXBSc2o1WXZFdUJfLUxBVUtGNk5SeFFrUS1mNmdTUGs4In0.eyJleHAiOjE3MDA0NjUxMzAsImlhdCI6MTcwMDQ2NDgzMCwiYXV0aF90aW1lIjoxNzAwNDY0Njg5LCJqdGkiOiIzZTk5YWI4Yi0xZTkyLTRlMDYtYjg0NC1kODc4ZDZjODZjOWMiLCJpc3MiOiJodHRwczovL2F1dGgubWVkLWxvLmV1L3JlYWxtcy9tZWQtbG8iLCJhdWQiOiJhY2NvdW50Iiwic3ViIjoiZGE5MDk4NDQtNjlmOS00ZjkzLWI1NjctMGZjOWQ3YzA3MTZmIiwidHlwIjoiQmVhcmVyIiwiYXpwIjoicm91bmRjdWJlIiwic2Vzc2lvbl9zdGF0ZSI6ImZkY2I2YTczLTNjNjgtNDlhNS1hOTlkLTdkYmE4ODNlNjg4NiIsImFjciI6IjAiLCJhbGxvd2VkLW9yaWdpbnMiOlsiaHR0cHM6Ly9tYWlsLm1lZC1sby5ldSJdLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsib2ZmbGluZV9hY2Nlc3MiLCJ1bWFfYXV0aG9yaXphdGlvbiIsImRlZmF1bHQtcm9sZXMtbWVkLWxvIl19LCJyZXNvdXJjZV9hY2Nlc3MiOnsiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgUm91bmRjdWJlX2VtYWlsIHByb2ZpbGUgZW1haWwgb3BlbmVkIiwic2lkIjoiZmRjYjZhNzMtM2M2OC00OWE1LWE5OWQtN2RiYTg4M2U2ODg2IiwiZW1haWxfdmVyaWZpZWQiOnRydWUsInBvc3RmaXhNYWlsQWRkcmVzcyI6ImZyYW5jaXNAbWVkLWxvLmV1IiwicG9zdGZpeE1haWxib3giOiJmcmFuY2lzQG1lZC1sby5ldSIsIm5hbWUiOiJGcmFuY2lzIEF1Z3VzdG8gTWVkZWlyb3MtTG9nZWF5IiwicHJlZmVycmVkX3VzZXJuYW1lIjoiZnJhbmNpcyIsImdpdmVuX25hbWUiOiJGcmFuY2lzIEF1Z3VzdG8iLCJmYW1pbHlfbmFtZSI6Ik1lZGVpcm9zLUxvZ2VheSIsImVtYWlsIjoiZnJhbmNpc0BtZWQtbG8uZXUifQ.Cehd8sbCTihfq1SKQitLTPfZZAWHx31sy8I6YydY_3eZvyHRellhQz1F9NxFt0uHaFk3KeddHV6U9z14qT7fStDp18ECJodSdcDt4k6J7geNjSbO3jSXOfk5JTbNPv0agi9e767E54g2ZkStPEezrAYY83msx7JSVpEmwKItSrDyyAWH44jp0OsnaLVCOZP1gBklTgiDt7uVsFwL9kpGamsMt62jNADnIAt6qLapHofiXi7GuIKdQP8-IG_7cCcpY6bEvcHiSgqhIpk5UHgMsljNQOkCKDpQ5rrTmRxloVF1y1zE7LYPNcugC_ZF_5TzxhVTEdEOLL9Q5epdlJvtvQ]: Submitted (requests left=1) Nov 20 08:20:30 auth: Debug: http-client: host auth.mydomain.com: DNS lookup successful; got 1 IPs Nov 20 08:20:30 auth: Debug: http-client: peer 10.10.100.10:443 (shared): Peer created Nov 20 08:20:30 auth: Debug: http-client: peer 10.10.100.10:443: Peer pool created Nov 20 08:20:30 auth: Debug: http-client[1]: peer 10.10.100.10:443: Peer created Nov 20 08:20:30 auth: Debug: http-client[1]: queue https://auth.mydomain.com:443: Setting up connection to 10.10.100.10:443 (SSL=auth.mydomain.com) (1 requests pending) Nov 20 08:20:30 auth: Debug: http-client[1]: peer 10.10.100.10:443: Linked queue https://auth.mydomain.com:443 (1 queues linked) Nov 20 08:20:30 auth: Debug: http-client[1]: queue https://auth.mydomain.com:443: Started new connection to 10.10.100.10:443 (SSL=auth.mydomain.com) Nov 20 08:20:30 auth: Debug: http-client[1]: peer 10.10.100.10:443: Creating 1 new connections to handle requests (already 0 usable, connecting to 0, closing 0) Nov 20 08:20:30 auth: Debug: http-client[1]: peer 10.10.100.10:443: Making new connection 1 of 1 (0 connections exist, 0 pending) Nov 20 08:20:30 auth: Debug: http-client: conn 10.10.100.10:443 [1]: Connecting Nov 20 08:20:30 auth: Debug: http-client: conn 10.10.100.10:443 [1]: Waiting for connect (fd=23) to finish for max 0 msecs Nov 20 08:20:30 auth: Debug: http-client: conn 10.10.100.10:443 [1]: HTTPS connection created (1 parallel connections exist) Nov 20 08:20:30 auth: Debug: http-client: conn 10.10.100.10:443 [1]: Client connection failed (fd=23) Nov 20 08:20:30 auth: Debug: http-client[1]: peer 10.10.100.10:443: Connection failed (1 connections exist, 0 pending) Nov 20 08:20:30 auth: Debug: http-client: peer 10.10.100.10:443: Failed to make connection (1 connections exist, 0 pending) Nov 20 08:20:30 auth: Debug: http-client[1]: peer 10.10.100.10:443: Failed to establish any connection within our peer pool: connect(10.10.100.10:443) failed: Connection refused (1 connections exist, 0 pending) Nov 20 08:20:30 auth: Debug: http-client[1]: queue https://auth.mydomain.com:443: Failed to set up connection to 10.10.100.10:443 (SSL=auth.mydomain.com):
Re: Avoiding POODLE vulnerability
On Sun, 2023-11-19 at 18:28 -0500, Steve Litt wrote: > > doveconf -d shows that I have no such config key as ssl_protocols, my > ssl_min_protocol is TLSv1.2, and the default ssl_cipher_list is the > following huge string: > > ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH > > Is the preceding the safest and most bug free, or should I modify it in > dovecot.conf? > That's the dovecot default and it's reasonably safe. If you're the only user, you can play around with it and watch the logs to see if it changes the cipher that your mail client negotiates... but otherwise you're more likely to create obscure problems than you are to improve anything. The string above is intended to enable all ciphers and then blacklist the weak ones. A few are excluded by name, but most are excluded via the LOW and EXPORT groups. (Newer versions of OpenSSL once again do this for you; man openssl-ciphers tells me that LOW, EXPORT, kDHd, and DES have all been removed as of openssl-1.1.0.) You could try to improve this by excluding (say) the MEDIUM group, but you risk breaking clients. The list above ends with @STRENGTH to prefer stronger ciphers. That means that if you have any clients connecting with a MEDIUM strength cipher, it's because they can't use anything better -- disabling MEDIUM will cause problems. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: [auth] epoll_ctl(add, 13) failed: Operation not permitted (fd doesn't support epoll)
> "Alexander" == Alexander Vogt via dovecot writes:
Is this a new setup? Do you have SELinux enabled? Or are you doing
chroot'd setup? If so, back it all off one by one and see what's
going on. The fact that you can't dump core because you can't write
somewhere tells me that your systems is locked down really hard in
some manner.
The fd not supporting epoll() is also suspect to me. Can you give
more details on your system setup? Do you have apparmor turned on?
Have you looked in your system logs as well?
John
> dovecot auth service is failing when using an inet_service. The
> configuration is essentially:
> service auth {
> inet_listener {
> address = *
> port = 12345
> }
> unix_listener auth-userdb {
> group = vmail
> mode = 0666
> user = vmail
> }
> }
> When I connect to port 12345 (real IMAP client or telnet doesn't make a
> difference), the auth service crashes.
> Nov 19 22:21:54 imap.linexus.de dovecot[7195]: auth: Panic:
> epoll_ctl(add, 13) failed: Operation not permitted (fd doesn't support
> epoll)
> Nov 19 22:21:54 imap.linexus.de dovecot[7195]: auth: Error: Raw
> backtrace: /usr/lib64/dovecot/libdovecot.so.0(backtrace_append+0x46)
> [0x7f9319f89486] ->
> /usr/lib64/dovecot/libdovecot.so.0(backtrace_get+0x22) [0x7f9319f895a2]
-> /usr/lib64/dovecot/libdovecot.so.0(+0x10a41b) [0x7f9319f9841b] ->
> /usr/lib64/dovecot/libdovecot.so.0(+0x10a4b7) [0x7f9319f984b7] ->
> /usr/lib64/dovecot/libdovecot.so.0(+0x5d11a) [0x7f9319eeb11a] ->
> /usr/lib64/dovecot/libdovecot.so.0(+0x609b0) [0x7f9319eee9b0] ->
> /usr/lib64/dovecot/libdovecot.so.0(+0x1215ba) [0x7f9319faf5ba] ->
> /usr/lib64/dovecot/libdovecot.so.0(io_add_to+0x1d) [0x7f9319faf62d] ->
> /usr/lib64/dovecot/libdovecot.so.0(io_add+0x28) [0x7f9319faf668] ->
> /usr/lib64/dovecot/libdovecot.so.0(master_service_io_listeners_add+0x8a
> ) [0x7f9319f1d16a] ->
> /usr/lib64/dovecot/libdovecot.so.0(master_service_init_finish+0xff)
> [0x7f9319f24bdf] -> dovecot/auth(main+0x389) [0x55745603a4f9] ->
> /lib64/libc.so.6(+0x3feb0) [0x7f931963feb0] ->
> /lib64/libc.so.6(__libc_start_main+0x80) [0x7f931963ff60] ->
> dovecot/auth(_start+0x25) [0x55745603a715]
> System info (sysreport attached):
> # 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.5.16 (09c29328)
> # OS: Linux 5.14.0-383.el9.x86_64 x86_64 CentOS Stream release 9
> This exact configuration is known to work on this system:
> # 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.4.21 (92477967)
> I tried for almost two hours to get a core dump for this, but finally
> gave up. I followed https://www.dovecot.org/bugreport-mail/#coredumps
> and other sources but the best I could get was
> Nov 19 22:21:54 imap.linexus.de dovecot[7195]: auth: Fatal: master:
> service(auth): child 7198 killed with signal 6 (core not dumped -
> https://dovecot.org/bugreport.html#coredumps - core wasn't writable?)
> for
> cat /proc/sys/kernel/core_pattern
> /tmp/core.%e.%p
> (which is 1777).
> Any help to get this resolved would be much appreciated!
> Thanks and best regards
> Alex
> [DELETED ATTACHMENT dovecot-sysreport-imap.linexus.de-1700427979.tar.gz,
> application/x-compressed-tar]
> ___
> 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: Avoiding POODLE vulnerability
Bernardo Reino said on Sun, 19 Nov 2023 09:04:15 +0100 (CET) >On Sun, 19 Nov 2023, Steve Litt wrote: > >> Michael Orlitzky said on Sat, 18 Nov 2023 17:31:49 -0500 >> >>> On Sat, 2023-11-18 at 16:54 -0500, Steve Litt wrote: I forgot to say: I'm using Dovecot 2.3.21 on an up to date 64 bit x86_64 Void Linux computer using runit for its init system. I populate Dovecot's Maildir via fetchmail and procmail. >>> >>> You probably don't have to do anything. SSLv2 and SSLv3 have been >>> disabled by default in OpenSSL for a while, and my dovecot default >>> is, >>> >>> # doveconf -d | grep ssl_min_protocol >>> ssl_min_protocol = TLSv1.2 >> >> Nice! I'll make that change tomorrow. Thanks! > >Note that the above is actually the *default*, at least in the debian >12 (bookworm) version, so you should not have do anything. > >(and generally it is not recommended to deviate from defaults unless >you really know what you're doing, otherwise you may end up actually >worsening the security wrt the defaults). > >Good luck. Thanks Bernardo, doveconf -d shows that I have no such config key as ssl_protocols, my ssl_min_protocol is TLSv1.2, and the default ssl_cipher_list is the following huge string: ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK:!RC4:!ADH:!LOW@STRENGTH Is the preceding the safest and most bug free, or should I modify it in dovecot.conf? Thanks, SteveT Steve Litt Autumn 2023 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
passdb doesn't support credential lookups
I'm having trouble authenticating certain users. I see this in the logs: Nov 19 16:26:40 auth: Debug: pam(jane,192.168.2.83,<...>): Performing passdb lookup Nov 19 16:26:40 auth: Debug: pam(jane,192.168.2.83,<...>): passdb doesn't support credential lookups Nov 19 16:26:40 auth: Debug: pam(jane,192.168.2.83,<...>): Finished passdb lookup at the command line, if I run this: % doveadm auth login jane Password: passdb: jane auth succeeded Oddly, I have a handfull of users that are failing and others that are not and I don't see the difference. signature.asc Description: PGP signature ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
[auth] epoll_ctl(add, 13) failed: Operation not permitted (fd doesn't support epoll)
Hi all,
dovecot auth service is failing when using an inet_service. The
configuration is essentially:
service auth {
inet_listener {
address = *
port = 12345
}
unix_listener auth-userdb {
group = vmail
mode = 0666
user = vmail
}
}
When I connect to port 12345 (real IMAP client or telnet doesn't make a
difference), the auth service crashes.
Nov 19 22:21:54 imap.linexus.de dovecot[7195]: auth: Panic:
epoll_ctl(add, 13) failed: Operation not permitted (fd doesn't support
epoll)
Nov 19 22:21:54 imap.linexus.de dovecot[7195]: auth: Error: Raw
backtrace: /usr/lib64/dovecot/libdovecot.so.0(backtrace_append+0x46)
[0x7f9319f89486] ->
/usr/lib64/dovecot/libdovecot.so.0(backtrace_get+0x22) [0x7f9319f895a2]
-> /usr/lib64/dovecot/libdovecot.so.0(+0x10a41b) [0x7f9319f9841b] ->
/usr/lib64/dovecot/libdovecot.so.0(+0x10a4b7) [0x7f9319f984b7] ->
/usr/lib64/dovecot/libdovecot.so.0(+0x5d11a) [0x7f9319eeb11a] ->
/usr/lib64/dovecot/libdovecot.so.0(+0x609b0) [0x7f9319eee9b0] ->
/usr/lib64/dovecot/libdovecot.so.0(+0x1215ba) [0x7f9319faf5ba] ->
/usr/lib64/dovecot/libdovecot.so.0(io_add_to+0x1d) [0x7f9319faf62d] ->
/usr/lib64/dovecot/libdovecot.so.0(io_add+0x28) [0x7f9319faf668] ->
/usr/lib64/dovecot/libdovecot.so.0(master_service_io_listeners_add+0x8a
) [0x7f9319f1d16a] ->
/usr/lib64/dovecot/libdovecot.so.0(master_service_init_finish+0xff)
[0x7f9319f24bdf] -> dovecot/auth(main+0x389) [0x55745603a4f9] ->
/lib64/libc.so.6(+0x3feb0) [0x7f931963feb0] ->
/lib64/libc.so.6(__libc_start_main+0x80) [0x7f931963ff60] ->
dovecot/auth(_start+0x25) [0x55745603a715]
System info (sysreport attached):
# 2.3.16 (7e2e900c1a): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.16 (09c29328)
# OS: Linux 5.14.0-383.el9.x86_64 x86_64 CentOS Stream release 9
This exact configuration is known to work on this system:
# 2.2.33.2 (d6601f4ec): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.21 (92477967)
I tried for almost two hours to get a core dump for this, but finally
gave up. I followed https://www.dovecot.org/bugreport-mail/#coredumps
and other sources but the best I could get was
Nov 19 22:21:54 imap.linexus.de dovecot[7195]: auth: Fatal: master:
service(auth): child 7198 killed with signal 6 (core not dumped -
https://dovecot.org/bugreport.html#coredumps - core wasn't writable?)
for
cat /proc/sys/kernel/core_pattern
/tmp/core.%e.%p
(which is 1777).
Any help to get this resolved would be much appreciated!
Thanks and best regards
Alex
dovecot-sysreport-imap.linexus.de-1700427979.tar.gz
Description: application/compressed-tar
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Avoiding POODLE vulnerability
On Sun, 2023-11-19 at 15:33 -0500, Steve Litt wrote: > > Thanks Bernardo, > > I use Void Linux, not Debian. Is there a command that tells me the > defaults? > The one I typed :) The doveconf command has a few flags that control what settings are displayed, and "-d" tells it to show the defaults as opposed to what is currently in use. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Avoiding POODLE vulnerability
Bernardo Reino said on Sun, 19 Nov 2023 09:04:15 +0100 (CET) >On Sun, 19 Nov 2023, Steve Litt wrote: > >> Michael Orlitzky said on Sat, 18 Nov 2023 17:31:49 -0500 >> >>> On Sat, 2023-11-18 at 16:54 -0500, Steve Litt wrote: I forgot to say: I'm using Dovecot 2.3.21 on an up to date 64 bit x86_64 Void Linux computer using runit for its init system. I populate Dovecot's Maildir via fetchmail and procmail. >>> >>> You probably don't have to do anything. SSLv2 and SSLv3 have been >>> disabled by default in OpenSSL for a while, and my dovecot default >>> is, >>> >>> # doveconf -d | grep ssl_min_protocol >>> ssl_min_protocol = TLSv1.2 >> >> Nice! I'll make that change tomorrow. Thanks! > >Note that the above is actually the *default*, at least in the debian >12 (bookworm) version, so you should not have do anything. > >(and generally it is not recommended to deviate from defaults unless >you really know what you're doing, otherwise you may end up actually >worsening the security wrt the defaults). Thanks Bernardo, I use Void Linux, not Debian. Is there a command that tells me the defaults? Thanks, SteveT Steve Litt Autumn 2023 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: [EXT] Replication going away?
Does anyone already have a dovecot (CE with Maildir) setup running using shared storage (i.ex. GlusterFS) underneath? This will be my current „migration plan“ to dovecot nmot supporting replication anymore: 2 x Loadblancers (accross two sites) with keepalived and haproxy 3x GlusterFS nodes 3x Galera Cluster mariadb nodes 2x dovecot IMAP with Postfix SMTP (wihout director there’s no need anynmore to use dovecot SMTP implementation) The Loadbalancer-, Galera- and Gluster modes are shared wit the existing web service infrastructure, so not dedicated to dovecot. So basically, this way I will not have to deploy a single node more without director/repication. If the HA storage and database clusters will be used for mail dedicated, this makes 11 nodes for a fully HA cluster accross two sites. With virtualization infrastructure that should get very expensive. Or am I missing something? Steven -- https://steven.varco.ch/ https://www.tech-island.com/ > Am 18.11.2023 um 18:10 schrieb Dean Carpenter : > > On 2023-07-20 5:31 pm, deano-dove...@areyes.com wrote: > On 2023-07-19 4:08 pm, Gerald Galster wrote: > A 50-100 mailbox user server > will run Dovecot CE just > fine. Pro would be overkill. >What is overkill? I always thought it >had a bit more features and support. > For Pro 2.3, you need (at minimum) 7 Dovecot > nodes + HA authentication + HA storage + > (minimum) 3 Cassandra nodes if using object > storage. This is per site; most of our customers > require data center redundancy as well, so > multiply as needed. And this is only email > retrieval; this doesn't even begin to touch upon > email transfer. Email high availability isn't > cheap. (I would argue that if you truly need this > sort of carrier-grade HA for 50 users, it makes > much more sense to use email as-a-service than > trying to do it yourself these days. Unless you > have very specific reasons and a ton of cash.) > High availability currently is cheap with a small two > server setup: > You need 3 servers or virtual machines: dovecot (and maybe > postfix) running on two of them and mysql galera on all > three. > This provides very affordable active/active geo-redundancy. > > No offence, it's just a pity to see that feature > disappering. > That's exactly how my own 3-node personal setup works. I shove all I > can into mariadb with galera (dovecot auth, spamassassin, etc) across > the 3 nodes. Dovecot replication keeps the 2 dovecot instances in > sync, the 3rd node is the quorum node for galera. > This is is on 3 cheap VPS' in 3 locations around the US. Mesh VPN > between them for the encrypted connectivity. It works, and it works > well. > And now replication is going away ? A perfectly-well working feature > is being removed ?? It's not as if it's a problematic one, nor would > it interfere with anything if it remained ... > I only see a couple of routes forward, at least for me. > * Stay on the last dovecot release that supports replication. > * Switch away from dovecot and cobble something else together. > * Move to gmail > The removal of replication feels very arbitrary. > At what version is replication being removed ? 2.4 I think ? Or, perhaps the > question is which is the last version that WILL still have replication ? > For now I'll be going with option 1 above, staying with the last version to > support it. Sad. > ___ > 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: Avoiding POODLE vulnerability
On Sun, 19 Nov 2023, Steve Litt wrote: Michael Orlitzky said on Sat, 18 Nov 2023 17:31:49 -0500 On Sat, 2023-11-18 at 16:54 -0500, Steve Litt wrote: I forgot to say: I'm using Dovecot 2.3.21 on an up to date 64 bit x86_64 Void Linux computer using runit for its init system. I populate Dovecot's Maildir via fetchmail and procmail. You probably don't have to do anything. SSLv2 and SSLv3 have been disabled by default in OpenSSL for a while, and my dovecot default is, # doveconf -d | grep ssl_min_protocol ssl_min_protocol = TLSv1.2 Nice! I'll make that change tomorrow. Thanks! Note that the above is actually the *default*, at least in the debian 12 (bookworm) version, so you should not have do anything. (and generally it is not recommended to deviate from defaults unless you really know what you're doing, otherwise you may end up actually worsening the security wrt the defaults). Good luck. ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
