similar to: Dovecot v2.3.11.3 released

Hi! We are pleased to release v2.3.14 of Dovecot. IMPORTANT NOTE: We have removed some components from the software, please review changelogs carefully prior upgrading. Please find source tarballs at https://dovecot.org/releases/2.3/dovecot-2.3.14.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.14.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in

Hi! We are pleased to release v2.3.14 of Dovecot. IMPORTANT NOTE: We have removed some components from the software, please review changelogs carefully prior upgrading. Please find source tarballs at https://dovecot.org/releases/2.3/dovecot-2.3.14.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.14.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in

We are pleased to release first release candidate for v2.3.14. We have done changes to packaging so please give us any feedback on how it works. https://dovecot.org/releases/2.3/rc/dovecot-2.3.14.rc1.tar.gz https://dovecot.org/releases/2.3/rc/dovecot-2.3.14.rc1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images are not available for this release candidate. Kind regards, Aki

We are pleased to release first release candidate for v2.3.14. We have done changes to packaging so please give us any feedback on how it works. https://dovecot.org/releases/2.3/rc/dovecot-2.3.14.rc1.tar.gz https://dovecot.org/releases/2.3/rc/dovecot-2.3.14.rc1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images are not available for this release candidate. Kind regards, Aki

Hello, my IdP is kind of progressive and implemented RFC9068, where all access tokens now come with typ "at+JWT". Since the setup has used local validation, I had to switch and currently use introspection endpoint. Looked around at the src and there seems to be relatively simple check of the token typ checking the only fixed value of "JWT" -- do you think you could consider

Open-Xchange Security Advisory 2021-06-21 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOV-4476 (Bug ID) Vulnerability type: CWE-24: Path Traversal: '../filedir' Vulnerable version: 2.3.11-2.3.14 Vulnerable component: imap, pop3, submission, managesieve Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.14.1 Vendor notification: 2021-03-22

Open-Xchange Security Advisory 2021-06-21 Product: Dovecot Vendor: OX Software GmbH Internal reference: DOV-4476 (Bug ID) Vulnerability type: CWE-24: Path Traversal: '../filedir' Vulnerable version: 2.3.11-2.3.14 Vulnerable component: imap, pop3, submission, managesieve Report confidence: Confirmed Solution status: Fixed by Vendor Fixed version: 2.3.14.1 Vendor notification: 2021-03-22

Hi Jeff, Thanks again for your insights. I understand that a lot of features are pending and it's totally fine, we're just very eager to use all these features. Reagarding the logging of failed attempts I did try to configure this in these two metrics: metric auth_client_userdb_lookup_finished { event_name = auth_client_userdb_lookup_finished group_by = service local_ip remote_ip

I'm running. dovecot --version 2.3.11.3 (502c39af9) solr -version 8.6.3 solr's configured to use SSL. dovecot correctly uses SSL for transport fts_solr = url=https://solr.example.com:8984/solr/dovecot/ adding solr-side SSL client auth, - SOLR_SSL_NEED_CLIENT_AUTH=false + SOLR_SSL_NEED_CLIENT_AUTH=need I need to specify client cert for dovecot to present -- specific to the

On 10/11/2020 4:27 PM, PGNet Dev wrote: > I'm running, > > dovecot --version > 2.3.11.3 (502c39af9) > > solr -version > 8.6.3 <snip> > Attempting to test/debug from from cmd line, > > doveadm fts lookup -u myuser at example.com body "tambien" > > causes a PANIC I am a committer on the lucene-solr project. So I know that product

re-reading your mail ... On 10/18/20 2:58 PM, Shawn Heisey wrote: > I do not use the fts-solr plugin, because my mail host in AWS does not have enough memory for that. is it that you're not using the dovecot plugin, but _DO_ have solr search setup? by what method/mean? or that you're avoiding solr usage altogether?

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

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

On 10/19/20 8:24 AM, John Fawcett wrote: > Depending how solr has been setup you could see the logging in the web > server access log. My access log is where I configured it in > /var/log/httpd/servername.access_log, yours may be different. here, not running a standalone webserver/proxy in front of solr. webui's provided by the built-in. my solr config atm, includes

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 >

On 19/10/2020 19:02, PGNet Dev wrote: > On 10/19/20 9:48 AM, John Fawcett wrote: >> --with-icu should be sufficient, actually on centos 7 I got libuci >> compiled in without setting the explicit flag. > >> Here's my ldd, which is under /usr/local/lib/dovecot >> >> ldd /usr/local/lib/dovecot/libdovecot-fts.so > > noted. as suspected. thx. > >>

On 19/10/2020 16:20, PGNet Dev wrote: > On 10/18/20 10:28 PM, Aki Tuomi wrote: >> Dovecot FTS tokenization is not done, unless you have `use_libfts` in >> fts_solr setting, in your case >> >> fts_solr = url=https://solr.example.com:8984/solr/dovecot/ use_libfts > > changing > > -??? fts_solr = url=https://solr.example.com:8984/solr/dovecot/ >

On 31/10/2020 04:57, PGNet Dev wrote: > On 10/18/20 10:28 PM, Aki Tuomi wrote: >>> ????doveadm(myuser at example.com): Panic: file mail-storage.c: line >>> 2112 (mailbox_get_open_status): assertion failed: (box->opened) > ... > >> I can reproduce your problem with the `fts lookup` command. Luckily >> it's equivalent to running `doveadm search`.

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 > I would be surprised if that had been fixed in the meantime. heh, sure. the 20 yr old

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 https://groups.google.com/forum/#!topic/tb-enterprise/TuUXyQLBB1o with leads to a comment from Timo https://www.mail-archive.com/dovecot