Re: 2.2.34 fails to build on OpenBSD

[Stuart Henderson]

On 2018-03-04, Brad Smith  wrote:
> Trying to build Dovecot 2.2.34 on OpenBSD fails.
>
> This seems to have been introduced by this commit..
> https://github.com/dovecot/core/commit/4a9020ed888caf03fd3132a30a7818b01daa4b9d

This is libtool-related.  GNU libtool prints a warning but is able to link:

$ /usr/local/bin/libtool  --tag=CC--mode=link cc  -I../../src/lib  
-I../../src/lib-test  -DMODULE_DIR=\""/usr/local/lib/dovecot"\" -std=gnu99 -O2 
-pipe -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith 
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier 
-Wstrict-aliasing=2 -L/usr/local/lib  -o test-ssl-iostream 
test_ssl_iostream-test-ssl-iostream.o libssl_iostream_openssl.la  
libssl_iostream.la  ../lib-test/libtest.la  ../lib/liblib.la  -export-dynamic 
*** Warning: Linking the executable test-ssl-iostream against the loadable 
module
*** libssl_iostream_openssl.so is not portable!
libtool: link: cc -I../../src/lib -I../../src/lib-test 
-DMODULE_DIR=\"/usr/local/lib/dovecot\" -std=gnu99 -O2 -pipe -Wall -W 
-Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts 
-Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier 
-Wstrict-aliasing=2 -o .libs/test-ssl-iostream 
test_ssl_iostream-test-ssl-iostream.o -Wl,-E  -L/usr/local/lib -L./.libs 
-lssl_iostream_openssl -lssl -lcrypto ./.libs/libssl_iostream.a 
../lib-test/.libs/libtest.a ../lib/.libs/liblib.a 
-Wl,-rpath,/usr/local/lib/dovecot
../lib/.libs/liblib.a(net.o): In function `net_connect_unix_with_retries':
net.c:(.text+0x852): warning: rand() may return deterministic values, is that 
what you want?

But it fails with OpenBSD libtool:

$ /usr/bin/libtool  --tag=CC--mode=link cc  -I../../src/lib  
-I../../src/lib-test  -DMODULE_DIR=\""/usr/local/lib/dovecot"\" -std=gnu99 -O2 
-pipe -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith 
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier 
-Wstrict-aliasing=2 -L/usr/local/lib  -o test-ssl-iostream 
test_ssl_iostream-test-ssl-iostream.o libssl_iostream_openssl.la  
libssl_iostream.la  ../lib-test/libtest.la  ../lib/liblib.la  -export-dynamic 
warning: library filename 
/usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib-ssl-iostream/.libs/libssl_iostream_openssl.so
 has no version number
libtool: link: cc -o .libs/test-ssl-iostream -I../../src/lib 
-I../../src/lib-test -DMODULE_DIR="/usr/local/lib/dovecot" -std=gnu99 -O2 -pipe 
-Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith 
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier 
-Wstrict-aliasing=2 -Wl,-E test_ssl_iostream-test-ssl-iostream.o 
/usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib-ssl-iostream/.libs/libssl_iostream.a
 /usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib-test/.libs/libtest.a 
/usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib/.libs/liblib.a -L.libs 
-lssl_iostream_openssl -lssl -lcrypto -Wl,-rpath,/usr/local/lib/dovecot
/usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib/.libs/liblib.a(net.o): In 
function `net_connect_unix_with_retries':
net.c:(.text+0x852): warning: rand() may return deterministic values, is that 
what you want?
.libs/libssl_iostream_openssl.so: undefined reference to 
`ssl_iostream_cert_match_name'
.libs/libssl_iostream_openssl.so: undefined reference to 
`ssl_iostream_context_deinit'
.libs/libssl_iostream_openssl.so: undefined reference to 
`ssl_iostream_handshake'
.libs/libssl_iostream_openssl.so: undefined reference to `ssl_iostream_unref'
.libs/libssl_iostream_openssl.so: undefined reference to 
`iostream_ssl_module_init'
.libs/libssl_iostream_openssl.so: undefined reference to 
`ssl_iostream_has_valid_client_cert'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
Error while executing cc -o .libs/test-ssl-iostream -I../../src/lib 
-I../../src/lib-test -DMODULE_DIR="/usr/local/lib/dovecot" -std=gnu99 -O2 -pipe 
-Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith 
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier 
-Wstrict-aliasing=2 -Wl,-E test_ssl_iostream-test-ssl-iostream.o 
/usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib-ssl-iostream/.libs/libssl_iostream.a
 /usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib-test/.libs/libtest.a 
/usr/obj/ports/dovecot-2.2.34/dovecot-2.2.34/src/lib/.libs/liblib.a -L.libs 
-lssl_iostream_openssl -lssl -lcrypto -Wl,-rpath,/usr/local/lib/dovecot

Clearly OpenBSD libtool isn't handling something that GNU libtool can cope
with, but given the warning from GNU libtool it doesn't seem entirely legit
in the first place.

2.2.34 broken if ssl_protocols contains !SSLv2

[Stuart Henderson]

The code in ssl_protocols_to_min_protocol() to convert ssl_protocols to
min/max values can't cope with strings containing "!SSLv2".

dovecot: imap-login: Fatal: Unknown ssl_protocols setting: Unrecognized 
protocol 'SSLv2'

This string might be configured explicitly by the user, or if the user
hasn't configured this themselves it could also come from the default
because master_service_ssl_default_settings sets this:

#ifdef SSL_TXT_SSLV2
.ssl_protocols = "!SSLv2 !SSLv3",
#else
.ssl_protocols = "!SSLv3",
#endif

Re: FTS Solr errors using doveadm

[Stuart Henderson]

On 2018-06-07, Ricardo Branco  wrote:
> Solr 7 returns JSON by default but fts_solr requires XML.
>
> Would be good to have wt=xml added to the query to force it to xml all the 
> time, this would prevent errors if solr has 
> not had xml set as default for index.

This is already done in Dovecot 2.3.x, the same patch works in 2.2.x.

https://github.com/dovecot/core/commit/f987ef0632fc.patch

Re: DMARC policies

[Stuart Henderson]

On 2018/11/30 10:55, Frederick Thomssen wrote:
> Hi guys
> 
> Why do I get these e-mails?

You were subscribed to the dovecot mailing list but probably had it set
to 'mail delivery: disabled' (possibly you read messages via archive
and have subscribed so you can reply, but don't want to receive email
copies of the messages).

Unsubscribe by sending mail to dovecot-requ...@dovecot.org with subject
'unsubscribe'.

Unsubscribe or change back to 'delivery: disabled' by web by going to
https://dovecot.org/mailman/options/dovecot

> On 30. 11. 18 10:50, gli...@gmail.com wrote:
> > Same problem here.
> > 
> > https://dovecot.org/mailman/options/dovecot-news
> > 
> > Sadly the remind password button / unsubscribe email button click and claim
> > to send me a email but they don't.
> > 
> > Assume its due a high mailq with the amount of messages that need to go out?

Give it time. If all the email addresses which were disabled due to
delivery failures have now been re-enabled, there are likely to be
messages to a bunch of failing addresses in the queue, it will take a
while before these get auto disabled again and things get back to
normal.

Hopefully there aren't too many invalid addresses in this set, too
many failures will trigger large mail hosts to start blocking the list
sender..

2.3.11.3 mail_cache_open_or_create_path called with null path

[Stuart Henderson]

Originally reported here -
https://marc.info/?l=openbsd-ports&m=159731598419071&w=2

OpenBSD's printf functions have a (mostly annoying but occasionally
useful) feature where they generate a syslog entry if printf %s format
is called with a null pointer.

It is tripped in lmtp/lda deliveries with 2.3.11.3:

lmtp: vfprintf %s NULL in "Cache %s: "
dovecot-lda: vfprintf %s NULL in "Cache %s: "

src/lib-index/mail-cache.c:
..
557 struct mail_cache *
558 mail_cache_open_or_create_path(struct mail_index *index, const char *path)
559 {
..
565 cache->filepath = i_strdup(path);
..
572 event_set_append_log_prefix(cache->event,
573 t_strdup_printf("Cache %s: ", cache->filepath);
..

Seems something is wrong to have this function called with no cache path?

Re: zlib errors after upgrading to 2.3.11.3

[Stuart Henderson]

On 2020-09-10, Timo Sirainen  wrote:
> We had a bunch of tests, but this required a large input buffer to be =
> feeded to the zstd compression code, which didn't happen all that =
> easily. I only accidentally caught it with the same test as I wrote for =
> reproducing the xz bug.
>
> Here's the list of fixes related to both xz and zstd:
>
>=
> https://github.com/dovecot/core/commit/48083d9e7fdbe257b0be33043ecf0ca8748=
> 9eef9 =
> 89eef9>
[...]

Will there be a release including these anytime soon?

Thanks.

Re: Indexer error after upgrade to 2.3.11.3

[Stuart Henderson]

On 2020-09-07, Scott Q.  wrote:
>
> Not sure if I mentioned it but I'm on FreeBSD too. I wonder if any
> of the patches FreeBSD applies automatically is causing this. I looked
> through them but couldn't find anything obvious that might cause this

FWIW also seen with 2.3.11.3 on OpenBSD, the only patches to code in the
OpenBSD port for this are unrelated.

Re: Indexer error after upgrade to 2.3.11.3

[Stuart Henderson]

On 2020/10/15 10:07, Scott Q. wrote:
> FWIW, I investigated this as much as I could...all I could find is that there 
> is some sort of
> difference in index files between versions. Once a user has been 'converted' 
> to 2.3.11.3 index
> files, the error went away.
> 
> On the other hand I was told that index file format hasn't changed in a long 
> time, so I really
> don't know what to think.

Thanks for the information. Hmm - I don't think it's directly that in my
case as I'm dsyncing to a new machine that has only ever run 2.3.11.3;
maybe they'll go away after the sync has finished though.

(Plus the index files themselves are in solr rather than anything
Dovecot-specific, admittedly I am using a newer schema version on the new
server though, the old one was ''
and new is 2.0).

> On Thursday, 15/10/2020 at 09:59 Stuart Henderson wrote:
> 
> On 2020-09-07, Scott Q.  wrote:
> >
> > Not sure if I mentioned it but I'm on FreeBSD too. I wonder if any
> > of the patches FreeBSD applies automatically is causing this. I looked
> > through them but couldn't find anything obvious that might cause this
> 
> FWIW also seen with 2.3.11.3 on OpenBSD, the only patches to code in the
> OpenBSD port for this are unrelated.
> 

2.13 read, i_stream_read_memarea: assertion failed: (!stream->blocking)

[Stuart Henderson]

I'm seeing this on some mailboxes with 2.13 on OpenBSD amd64 (recent
snapshot):

dovecot: imap(sthen)<47220>: Panic: file istream.c: line 332 
(i_stream_read_memarea): assertion failed: (!stream->blocking)

Using sieve, imapsieve, replicator, zlib (zlib_save = lz4 and has
been for some time, so the relevant messages probably use this).
Using mmap_disable because OpenBSD.

Any suggestions how to handle it, preferably automatically?
(even if a message is corrupt/lost it would be really nice if a
standard client could still access the mailbox rather than kill
the imap process while reading headers).

bt first for ease of reading, followed by bt full in case it has any
additional clues.

(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x0e9158c7c3ae in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x0e91adc00c26 in default_fatal_finish (type=LOG_TYPE_PANIC, status=0) 
at failures.c:459
#3  0x0e91adbff034 in fatal_handler_real (ctx=0x7f7cdd90, 
format=,
args=) at failures.c:471
#4  0x0e91adbfffb1 in i_internal_fatal_handler (ctx=0x0,
format=0x6 , args=0x0) at 
failures.c:866
#5  0x0e91adbff266 in i_panic (format=0x6 )
at failures.c:523
#6  0x0e91adc0f15c in i_stream_read_memarea (stream=0xe917ead3480) at 
istream.c:332
#7  0x0e91adc1925f in read_more (sstream=0xe91431c4800) at 
istream-seekable.c:149
#8  0x0e91adc19090 in read_from_buffer (sstream=0xe91431c4800, 
ret_r=0x7f7cded8)
at istream-seekable.c:204
#9  0x0e91adc1856d in i_stream_seekable_read (stream=0xe91431c4800) at 
istream-seekable.c:265
#10 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91431c4880) at 
istream.c:313
#11 0x0e91adc16bbc in i_stream_limit_read (stream=0xe91e9ccca00) at 
istream-limit.c:49
#12 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91e9ccca80) at 
istream.c:313
#13 0x0e91adc0f79c in i_stream_read_copy_from_parent (istream=) at istream.c:387
#14 0x0e918e9729fa in i_stream_mail_read (stream=0xe91e9ccc000) at 
istream-mail.c:115
#15 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91e9ccc080) at 
istream.c:313
#16 0x0e91adc104f5 in i_stream_read (stream=0xe91e9ccc080) at istream.c:271
#17 i_stream_read_data (stream=0xe91e9ccc080, data_r=0x7f7ce110, 
size_r=0x7f7ce100, threshold=1)
at istream.c:747
#18 0x0e91adbd6a18 in i_stream_read_bytes (stream=0x0, data_r=,
size_r=, wanted=) at 
../../src/lib/istream.h:214
#19 message_parse_header_next (ctx=0xe9183e1b180, hdr_r=0x7f7ce1d0) at 
message-header-parser.c:85
#20 0x0e91adbceef2 in read_header (mstream=0xe91e9cc6000) at 
istream-header-filter.c:195
#21 i_stream_header_filter_read (stream=0xe91e9cc6000) at 
istream-header-filter.c:450
#22 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91e9cc6080) at 
istream.c:313
#23 0x0e91adc104f5 in i_stream_read (stream=0xe91e9cc6080) at istream.c:271
#24 i_stream_read_data (stream=0xe91e9cc6080, data_r=0x7f7ce2c0, 
size_r=0x7f7ce2c8, threshold=0)
at istream.c:747
#25 0x0e91adbdc07b in i_stream_read_bytes (stream=0xe91e9cc6080, 
data_r=,
size_r=, wanted=)
at ../../src/lib/istream.h:214
#26 message_get_header_size (input=0xe91e9cc6080, hdr=0x7f7ce328, 
has_nuls_r=0x7f7ce3b7)
at message-size.c:19
#27 0x0e8f25e767d9 in imap_msgpart_get_partial_header (mail=0xe91e9cc4848,
mail_input=, msgpart=0xe91c92a2048, 
virtual_size_r=,
result_r=0x7f7ce408, have_crlfs_r=) at imap-msgpart.c:401
#28 imap_msgpart_open_normal (mail=, msgpart=0xe91c92a2048, 
part=,
virtual_size_r=, result_r=0x7f7ce408, 
have_crlfs_r=)
at imap-msgpart.c:637
#29 imap_msgpart_open (mail=, msgpart=0xe91c92a2048, 
result_r=0x7f7ce408)
at imap-msgpart.c:706
#30 0x0e8f25e672ff in fetch_body_msgpart (ctx=0xe9159845368, 
mail=,
body=0xe91e9cb4398) at imap-fetch-body.c:184
#31 0x0e8f25e65837 in imap_fetch_more_int (ctx=0xe9159845368, cancel=false) 
at imap-fetch.c:562
#32 0x0e8f25e6552c in imap_fetch_more (ctx=0xe9159845368, 
cmd=0xe9159845048) at imap-fetch.c:617
#33 0x0e8f25e55521 in cmd_fetch (cmd=0xe9159845048) at cmd-fetch.c:337
#34 0x0e8f25e62d12 in command_exec (cmd=0xe9159845048) at 
imap-commands.c:201
#35 0x0e8f25e61576 in client_command_input (cmd=0xe9159845048) at 
imap-client.c:1204
#36 0x0e8f25e61682 in client_command_input (cmd=0xe9159845048) at 
imap-client.c:1269
#37 0x0e8f25e5ffb4 in client_handle_next_command (client=0xe9159845848, 
remove_io_r=)
at imap-client.c:1313
#38 client_handle_input (client=0xe9159845848) at imap-client.c:1327
#39 0x0e8f25e5e755 in client_input (client=0xe9159845848) at 
imap-client.c:1371
#40 0x0e91adc1c851 in io_loop_call_io (io=0xe91eb5d0b00) at ioloop.c:714
#41 0x0e91adc1f84c in io_loop_handler_run_internal (ioloop=0xe9162373d00) 
at ioloop-kqueue.c:164
#42 0x0e91adc1cfd9 in io_loop_handler_run (ioloop=0xe9162373d00) at 
ioloop.c:766
#43 0x0e91adc1cce8 in io_loop_run (ioloop=0xe

Re: Dovecot and mutt

[Stuart Henderson]

On 2021-01-25, @lbutlr  wrote:
> I get a LOT of mail that is pointlessly HTMLized (including on this list)

*especially* on this list, for some reason.

Re: 2.13 read, i_stream_read_memarea: assertion failed: (!stream->blocking)

[Stuart Henderson]

On 2021-01-24, Stuart Henderson  wrote:
> I'm seeing this on some mailboxes with 2.13 on OpenBSD amd64 (recent
> snapshot):
>
> dovecot: imap(sthen)<47220>: Panic: file istream.c: line 
> 332 (i_stream_read_memarea): assertion failed: (!stream->blocking)
>
> Using sieve, imapsieve, replicator, zlib (zlib_save = lz4 and has
> been for some time, so the relevant messages probably use this).
> Using mmap_disable because OpenBSD.
>
> Any suggestions how to handle it, preferably automatically?
> (even if a message is corrupt/lost it would be really nice if a
> standard client could still access the mailbox rather than kill
> the imap process while reading headers).

Thought I'd try doveadm force-resync ("For sdbox and mdbox mailboxes the
storage files will be also checked") but this doesn't help.

Getting some ideas for the seemingly related thread about zstd/xz
https://dovecot.org/pipermail/dovecot/2020-September/119890.html I've had
a play with doveadm fetch.

Doing 'doveadm fetch -u sthen "uid text" mailbox ports | grep ^uid | tail'
I find various messages from around June/July 2020 that trigger the crash.
Expunging the last displayed uid at that point I get further but I run into
more after a few messages. I don't mind doing that with this mailbox to
get things working but if it can be used to provide/test something more
robust that would be better.

Using "doveadm -o mail_plugins=virtual fetch" I see that they're definitely
lz4 compressed.

Seems odd but if I do text fetches by uid I don't run into any failure?

$ for i in `cat /tmp/uid.p|cut -d: -f2`;do doveadm fetch -u sthen text mailbox 
ports uid $i > /dev/null || echo $i;done
[no output]

Any ideas?



> bt first for ease of reading, followed by bt full in case it has any
> additional clues.
>
> (gdb) bt
> #0  thrkill () at /tmp/-:3
> #1  0x0e9158c7c3ae in _libc_abort () at 
> /usr/src/lib/libc/stdlib/abort.c:51
> #2  0x0e91adc00c26 in default_fatal_finish (type=LOG_TYPE_PANIC, 
> status=0) at failures.c:459
> #3  0x0e91adbff034 in fatal_handler_real (ctx=0x7f7cdd90, 
> format=,
> args=) at failures.c:471
> #4  0x0e91adbfffb1 in i_internal_fatal_handler (ctx=0x0,
> format=0x6 , args=0x0) at 
> failures.c:866
> #5  0x0e91adbff266 in i_panic (format=0x6  address 0x6>)
> at failures.c:523
> #6  0x0e91adc0f15c in i_stream_read_memarea (stream=0xe917ead3480) at 
> istream.c:332
> #7  0x0e91adc1925f in read_more (sstream=0xe91431c4800) at 
> istream-seekable.c:149
> #8  0x0e91adc19090 in read_from_buffer (sstream=0xe91431c4800, 
> ret_r=0x7f7cded8)
> at istream-seekable.c:204
> #9  0x0e91adc1856d in i_stream_seekable_read (stream=0xe91431c4800) at 
> istream-seekable.c:265
> #10 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91431c4880) at 
> istream.c:313
> #11 0x0e91adc16bbc in i_stream_limit_read (stream=0xe91e9ccca00) at 
> istream-limit.c:49
> #12 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91e9ccca80) at 
> istream.c:313
> #13 0x0e91adc0f79c in i_stream_read_copy_from_parent (istream= out>) at istream.c:387
> #14 0x0e918e9729fa in i_stream_mail_read (stream=0xe91e9ccc000) at 
> istream-mail.c:115
> #15 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91e9ccc080) at 
> istream.c:313
> #16 0x0e91adc104f5 in i_stream_read (stream=0xe91e9ccc080) at 
> istream.c:271
> #17 i_stream_read_data (stream=0xe91e9ccc080, data_r=0x7f7ce110, 
> size_r=0x7f7ce100, threshold=1)
> at istream.c:747
> #18 0x0e91adbd6a18 in i_stream_read_bytes (stream=0x0, data_r= out>,
> size_r=, wanted=) at 
> ../../src/lib/istream.h:214
> #19 message_parse_header_next (ctx=0xe9183e1b180, hdr_r=0x7f7ce1d0) at 
> message-header-parser.c:85
> #20 0x0e91adbceef2 in read_header (mstream=0xe91e9cc6000) at 
> istream-header-filter.c:195
> #21 i_stream_header_filter_read (stream=0xe91e9cc6000) at 
> istream-header-filter.c:450
> #22 0x0e91adc0f0a4 in i_stream_read_memarea (stream=0xe91e9cc6080) at 
> istream.c:313
> #23 0x0e91adc104f5 in i_stream_read (stream=0xe91e9cc6080) at 
> istream.c:271
> #24 i_stream_read_data (stream=0xe91e9cc6080, data_r=0x7f7ce2c0, 
> size_r=0x7f7ce2c8, threshold=0)
> at istream.c:747
> #25 0x0e91adbdc07b in i_stream_read_bytes (stream=0xe91e9cc6080, 
> data_r=,
> size_r=, wanted= memory at address 0x1>)
> at ../../src/lib/istream.h:214
> #26 message_get_header_size (input=0xe91e9cc6080, hdr=0x7f7ce328, 
> has_nuls_r=0x7f7ce3b7)
> at message-size.c:19
> #27 0x0e8f25e767d9 in imap_msgpart_get_partial_header (mail=0xe91e9cc4848,
> mail_input=, msgp

Re: 2.13 read, i_stream_read_memarea: assertion failed: (!stream->blocking)

[Stuart Henderson]

On 2021/01/28 14:51, Aki Tuomi wrote:
> Hi!
> 
> Would it be possible for you to provide the mail through obfuscation.
> 
> You can use https://dovecot.org/tools/maildir-obfuscate.pl for this purpose.
> 
> If you are using maildir format, you can decompress the mail with lz4 
> decompression tool. If you are using dbox format, it's slightly trickier as 
> you need to remove the container around the mail first, and then decompress 
> it.

It's mdbox (sorry I thought I had mentioned that earlier but seems I missed
it).

So here's the tail of output from doveadm -u sthen fetch "uid text" mailbox 
ports

--snip--snip--snip--
uid: 34088
text:
Return-Path: 
[...]
> www/seamonkey   Could not find gconf-2.0
> -> seems repeatable but I don't understand why py3 would be involved
> so maybe it's fallout from something else
> 
> graphics/vulkan-tools   'time' has no attribute 'clock'
> -> port is outdated; this was fixed as part doveadm(sthen): Panic: file 
> istream.c: line 332 (i_stream_read_memarea): assertion failed: 
> (!stream->blocking)
--snip--snip--snip--

The actual message has a few more lines, it's a public list post so I can
compare 'doveadm fetch -u sthen "uid text" mailbox ports uid 34088' against
https://marc.info/?l=openbsd-ports&m=159372656616988&q=raw and see that it
is fetched completely.

So, on to extracting the compressed mail, and this might give some clues:

$ doveadm -o mail_plugins=virtual fetch -u sthen text mailbox ports uid 34088 > 
34088.z
doveadm(sthen): Error: Mailbox ports: Deleting corrupted cache record 
uid=34088: UID 34088: Broken physical size in mailbox ports: 
read(/home/sthen/mdbox/storage/m.6167) failed: Cached message size larger than 
expected (8851 > 4542, box=ports, UID=34088)
doveadm(sthen): Error: read(/home/sthen/mdbox/storage/m.6167) failed: Cached 
message size larger than expected (8851 > 4542, box=ports, UID=34088)
doveadm(sthen): Error: fetch(text) failed for box=ports uid=34088: 
read(/home/sthen/mdbox/storage/m.6167) failed: Cached message size larger than 
expected (8851 > 4542, box=ports, UID=34088)

$ tail -n +2 34088.z > 34088.zz
$ doveadm fs get compress lz4:0:posix 34088.zz > plain
..and (not surprising since the message is displayed OK with "fetch ... uid")
the complete message is there..

If I try fetching that message again I no longer see the "Deleting
corrupted cache record" but I do still get a crash at the same point
if I fetch text for the whole mailbox.

Looking at the visible bits in that mdbox file I don't think I will be
able to identify the various correspondents enough to get their
permission to provide the whole file. (The list mail is public anyway,
but from what I can make out past the lz4 there's at least some private
mail in the file). But happy to dig around in there if there's
anything that might help, I can be /m'd on freenode (sthen) if real-
time is better for that.



> Aki
> 
> > On 28/01/2021 14:45 Stuart Henderson  wrote:
> > 
> >  
> > On 2021-01-24, Stuart Henderson  wrote:
> > > I'm seeing this on some mailboxes with 2.13 on OpenBSD amd64 (recent
> > > snapshot):
> > >
> > > dovecot: imap(sthen)<47220>: Panic: file istream.c: 
> > > line 332 (i_stream_read_memarea): assertion failed: (!stream->blocking)
> > >
> > > Using sieve, imapsieve, replicator, zlib (zlib_save = lz4 and has
> > > been for some time, so the relevant messages probably use this).
> > > Using mmap_disable because OpenBSD.
> > >
> > > Any suggestions how to handle it, preferably automatically?
> > > (even if a message is corrupt/lost it would be really nice if a
> > > standard client could still access the mailbox rather than kill
> > > the imap process while reading headers).
> > 
> > Thought I'd try doveadm force-resync ("For sdbox and mdbox mailboxes the
> > storage files will be also checked") but this doesn't help.
> > 
> > Getting some ideas for the seemingly related thread about zstd/xz
> > https://dovecot.org/pipermail/dovecot/2020-September/119890.html I've had
> > a play with doveadm fetch.
> > 
> > Doing 'doveadm fetch -u sthen "uid text" mailbox ports | grep ^uid | tail'
> > I find various messages from around June/July 2020 that trigger the crash.
> > Expunging the last displayed uid at that point I get further but I run into
> > more after a few messages. I don't mind doing that with this mailbox to
> > get things working but if it can be used to provide/test something more
> > robust that wou

Re: Undefined SSL object

[Stuart Henderson]

On 2021-01-30, Frank Elsner  wrote:
> Hi community,
>
> when doing imapsync to my dovecot server (Host2) I get the following
>
> Host2 capability before authentication: IMAP4rev1 SASL-IR LOGIN-REFERRALS ID 
> ENABLE IDLE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN AUTH
> DEBUG: .../IO/Socket/SSL.pm:1117: global error: Undefined SSL object
> Host2: Socket successfuly converted to SSL
>
> Beside this message all works fine.
> What is it? SSL setting? How to overcome the message?

This message is coming from the client. The obvious workaround is
to turn off debugging (looks like maybe --debugssl 0 does that),
If not then try the imapsync mailing list.

Re: fts_encoder

[Stuart Henderson]

On 2021-02-08, Joan Moreau  wrote:
> Well, in the function xxx_build_more of FTS plugin, the data received in 
> the original PDF, not the output of pdftotext
>
> Can you clarify where do you put your log in the solr plugin , so I can 
> check the situation in the xapian plugin ?

The log is particular to fts_solr, you set it with e.g.

"fts_solr = url=http://127.0.0.1:8983/solr/dovecot/ rawlog_dir=/tmp/solr"

Confirmed it works for me, i.e. passes text from inside the pdf, and not
the whole pdf itself.

Did you check that decode2text.sh works ok on your system (when running
as the relevant uid)?

cat foo.pdf | sudo -u dovecot /usr/libexec/dovecot/decode2text.sh 
application/pdf

Re: fts_encoder

[Stuart Henderson]

On 2021/02/08 21:33, Joan Moreau wrote:
> Yes , once again : output of the decoder is fine, I also put log inide the 
> dovecot core to
> check whether data is properly transmitted, and result is that it is (i.e. 
> dovecot core
> receives the proper output of pdftotext via the decoder
> 
> Now, that data is the /not/ the one sent from dovecot core to the fts plugin 
> (and this is the
> same issue for solr and all other plugins)

Seems that something is different with your setup than John's and mine
then, as fts_solr rawlog (which is just the http request split into
.in and .out files) has the decoded file for us.

Did you try with the actual fts_solr plugin so it's a direct comparison
with what we see? There is no need for a real solr server, just point it
at any http server (or I guess netcat listening on a port will also do)
with

mail_plugins = fts fts_solr

plugin {
  fts_autoindex = yes
  fts = solr
  fts_solr = url=http://127.0.0.1:80/ rawlog_dir=/tmp/solr
}

If that is not showing decoded for you then I suppose there's some
problem on the way into/through fts. And if it does show as decoded
then perhaps fts_solr is doing something slightly different than the
places you're examining in fts and your plugin, and that might give
a point to work backwards from.

Re: Latest dovecot does not work with latest MUA (thunderbird)

[Stuart Henderson]

On 2021-03-14, lja@koti  wrote:
> # 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf

That's nowhere near the latest Dovecot.

Re: bug: some table header(?) output goes to stderr instead of stdout

[Stuart Henderson]

On 2021-03-18, Marc  wrote:
>
> [@ sbin]# doveadm -f table -o 
> mail_location=mdbox_deleted:/home/popusers/testtest/mdbox:INDEX=/home/popindex/testtest/index
>  fetch -u testtest 'guid' mailbox INBOX 2> /dev/null
> 3c967f33b8aea671f3551db1ea8e33e9
> 6fa01ccc103a7009c7b940657dbcd72c
> ba955a6d6218950f42e5b0ee0a33a916
>
> [@ sbin]# doveadm -f table -o 
> mail_location=mdbox_deleted:/home/popusers/testtest/mdbox:INDEX=/home/popindex/testtest/index
>  fetch -u testtest 'guid' mailbox INBOX
> guid
> 3c967f33b8aea671f3551db1ea8e33e9
> 6fa01ccc103a7009c7b940657dbcd72c
> ba955a6d6218950f42e5b0ee0a33a916
>
>
>

That's a useful feature, saves messing about to exclude the headers when you
want to use the results to fetch messages as shown in doveadm-search(1).

Re: Dovecot 2.3.15 (was Re: Dovecot 2.3.15 compilation fails)

[Stuart Henderson]

On 2021-06-29, @lbutlr  wrote:
> On 27 Jun 2021, at 05:38, Andreas M. Kirchwitz  wrote:
>> Dovecot 2.3.15
>
> On FreeBSD 13.0 I am seeing that my installed version, 2.3.13_1 is the newest 
> dovecot.
>
> I've been checking since I have some CVEs on that version, but no update yet.
>
> Any timeline for FreeBSD
>

That would be a question for the FreeBSD port maintainer.

Re: Sieve vacation + SRS + forwarded e-mail

[Stuart Henderson]

On 2021-07-09, Saarts, Erik  wrote:
> We have domain A on cloud, from where mail gets forwarded to our local
> server to domain B. Forwarding is done in
> SPF-compliant way by using SRS (this part we have no control
> over).=C2=A0=C2=A0This SRS address ends up in
> Return-Path header, and sieve vacation replies to=C2=A0this address.
>
>
> This is all absolutely correct, but also useless, as sending mail to
> SRS address leads nowhere.

That's a broken SRS setup then, if it doesn't handle responses to the
sender address there will be some lost mail. Vacation and similar auto
responses are _required_ to reply to the SMTP sender address.

Re: Sv: 2FA/MFA with IMAP & postfix/submission

[Stuart Henderson]

On 2021-07-15, Sebastian  wrote:
> Best solution is to offer a webmail with TOTP or SQRL or similiar secure =
> auth method.
>
> Then have that webmail adds IP or country into trusted list, so if you =
> want to access IMAP mail or SMTP mail from hotel wifi, you have to =
> simply do one single login to webmail, and then your IMAP/SMTP will work =
> as usual.

As long as the IMAP/SMTP access is coming from the same ISP as the web
access and not, for example, natted to one IP whereas the web traffic
is coming from a proxy, or natted to a pool of addresses (or balanced
between multiple internet connections) where you don't always get the
same external address.

i_stream_read_memarea: assertion failed: (!stream->blocking)

[Stuart Henderson]

Continuation of https://dovecot.org/pipermail/dovecot/2021-January/121235.html
- I didn't get a reply to my last mail, so ended up deleting the various
messages (or in some cases mailboxes) and stopped running into problems for
a while, but am now seeing it again.

I get "i_stream_read_memarea: assertion failed: (!stream->blocking)" when
accessing some messages. Backtrace and doveconf -n below.

$ doveadm -D search from abcdefghij
[...]
Aug 13 17:30:02 doveadm(sthen): Debug: Mailbox trash: UID 1177: Looked up field 
guid from mail cache
Aug 13 17:30:02 doveadm(sthen): Debug: Mailbox trash: UID 1177: Opened mail 
because: 1/1 headers not cached (first=from) (Mail has other cached fields, 
reset_id=1470764070)
Aug 13 17:30:02 doveadm(sthen): Debug: Mailbox trash: UID 1178: Looked up field 
guid from mail cache
Aug 13 17:30:02 doveadm(sthen): Debug: Mailbox trash: UID 1178: Looked up field 
guid from mail cache
Aug 13 17:30:02 doveadm(sthen): Debug: Mailbox trash: UID 1178: Looked up field 
guid from mail cache
Aug 13 17:30:02 doveadm(sthen): Debug: Mailbox trash: UID 1178: Opened mail 
because: 1/1 headers not cached (first=from) (Mail has other cached fields, 
reset_id=1470764070)
Aug 13 17:30:02 doveadm(sthen): Panic: file istream.c: line 345 
(i_stream_read_memarea): assertion failed: (!stream->blocking)
Abort trap (core dumped) 

Some other searches hitting the same message do succeed though e.g.
"doveadm search mailbox trash".

Somehow after various other searches trying to figure out what triggered
the crash and what didn't (e.g. "doveadm -D search mailbox trash uid 1170:12000
from abc" crashed but "uid 1170:1190" didn't) it has stopped failing with that
particular message, but I am still hitting it in at least one other mailbox.

The messages where I'm seeing this so far seem to all be stored with lz4 (a
couple of years old mostly). 

Any ideas?


GNU gdb (GDB) 7.12.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd6.9".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from doveadm...Reading symbols from 
/usr/local/bin/.debug/doveadm.dbg...done.
done.
[New process 130792]
Core was generated by `doveadm'.
Program terminated with signal SIGABRT, Aborted.
#0  thrkill () at /tmp/-:3
3   /tmp/-: No such file or directory.
(gdb) bt
#0  thrkill () at /tmp/-:3
#1  0x0c3b2a1ee58e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2  0x0c3b2780f876 in default_fatal_finish (type=LOG_TYPE_PANIC, status=0) 
at failures.c:459
#3  0x0c3b2780dc94 in fatal_handler_real (ctx=0x7f7cb040,
format=,
args=) at 
failures.c:471
#4  0x0c3b2780dc51 in default_fatal_handler (ctx=0x0,
format=0x6 , args=0x0) at 
failures.c:479
#5  0x0c3b2780ded2 in i_panic (format=0x6 ) at failures.c:524
#6  0x0c3b2781db26 in i_stream_read_memarea (stream=0xc3b41c94080) at 
istream.c:345
#7  0x0c3b27827c2f in read_more (sstream=0xc3b41c80c00) at 
istream-seekable.c:152
#8  0x0c3b27827a70 in read_from_buffer (sstream=0xc3b41c80c00, 
ret_r=0x7f7cb188)
at istream-seekable.c:207
#9  0x0c3b27826f67 in i_stream_seekable_read (stream=0xc3b41c80c00) at 
istream-seekable.c:269
#10 0x0c3b2781da74 in i_stream_read_memarea (stream=0xc3b41c80c80) at 
istream.c:326
#11 0x0c3b2782568c in i_stream_limit_read (stream=0xc3b1097d000) at 
istream-limit.c:51
#12 0x0c3b2781da74 in i_stream_read_memarea (stream=0xc3b1097d080) at 
istream.c:326
#13 0x0c3b2781e16c in i_stream_read_copy_from_parent (istream=) at istream.c:400
#14 0x0c3bc821b24a in i_stream_mail_read (stream=0xc3b41c83200) at 
istream-mail.c:115
#15 0x0c3b2781da74 in i_stream_read_memarea (stream=0xc3b41c83280) at 
istream.c:326
#16 0x0c3b2781ef0a in i_stream_read (stream=0xc3b41c83280) at istream.c:283
#17 i_stream_read_data (stream=0xc3b41c83280, data_r=0x7f7cb3b8, 
size_r=0x7f7cb3b0, threshold=1)
at istream.c:760
#18 0x0c3b277e4016 in i_stream_read_bytes (stream=0x0, data_r=, size_r=,
wanted=) at ../../src/lib/istream.h:220
#19 message_parse_header_next (ctx=0xc3b109a4300, hdr_r=0x7f7cb470) at 
message-header-parser.c:85
#20 0x0c3b277dc5f2 in read_header (mstream=0xc3b41cb0800) at 
istream-header-filter.c:195
#21 i_stream_header_filter_read (stream=0xc3b41cb0800) at 
istream-header-filter.c:450
#22 0x0c3b2781da74 in i_stream_read_memarea (stream=0xc3b41cb0880) at 
istream.c:

Re: i_stream_read_memarea: assertion failed: (!stream->blocking)

[Stuart Henderson]

On 2021/08/16 13:32, Timo Sirainen wrote:
> On 13. Aug 2021, at 19.10, Stuart Henderson  wrote:
> > I get "i_stream_read_memarea: assertion failed: (!stream->blocking)" when
> > accessing some messages. Backtrace and doveconf -n below.
> 
> Does the attached patch fix it?

It does - thank you.

Re: SSL errors after certificate renewal

[Stuart Henderson]

On 2021-09-07, N  wrote:
> Separate subject, but couldn't help but notice, SSL3 is being used?
> Wasn't SSL3 retired because of POODLE exploits? Can someone more 
> knowledgeable confirm?

"sslv3 alert certificate unknown" does not mean that SSLv3 is used.

Re: SSL errors after certificate renewal

[Stuart Henderson]

On 2021-09-07, Amol Kulkarni  wrote:
> After I replaced my certificate with a new one yesterday, I'm seeing some
> ssl related errors. There are successful pop/imap logins using SSL also. So
> I think the certificate in itself is fine. No user has complained as yet,
> so I don't know for sure. However the count of errors has surely increased
> after installing the new certificate.
> There are 2 errors seen :
> dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>,
> rip=, lip
>=, TLS handshaking: SSL_accept() failed: error:14094416:SSL
> routines:SSL3_READ_BYTES:sslv3 alert certificate unknown: SSL alert number
> 46, session=<9m0AnVnL
> 2pHf4hso>
>
>
> dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>,
> rip=, lip
>=, TLS: SSL_read() failed: error:14094412:SSL
> routines:SSL3_READ_BYTES:sslv3 alert bad certificate: SSL alert number 42,
> session=
>
> Kindly help with some pointers.

If you mention the hostname we can check the actual problem, otherwise we
have to guess.

Certificates are usually issued from an intermediate, not directly from a
CA. Servers need to be configured to send that intermediate. Some (mostly
GUI) clients will fetch a missing intermediate automatically but most mail
clients won't.

The most common problem associated with changing cert is to forget to
include the intermediate in the server config. Check with this:

openssl s_client -starttls imap -servername $hostname -connect $hostname:143

The chain should normally look something like this for a letsencrypt cert;
other CAs will usually also have 3 entries but the names will differ

---
Certificate chain
 0 s:/CN=$hostname
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

The final "i" line needs to be in the root CA store on the client machine.

The file used for "ssl_cert" in Dovecot (and same for most other services)
needs to contain both the server certificate and the intermediate.
Commercial CAs usually provide this in a zip or similar file with the
cert. ACME clients for letsencrypt etc will usually download it
automatically or can be configured to do so (certbot writes both to a
"fullchain.pem" file which can be used directly).

If that doesn't help, post the hostname for a proper analysis.

Re: SNI via lookup?

[Stuart Henderson]

On 2021-10-07, Felipe Gasper  wrote:
>> On Oct 7, 2021, at 7:47 PM, Benny Pedersen  wrote:
>> 
>> https://dovecot.org/pipermail/dovecot/2013-December/094214.html
>
> SNI’s security problem is that the server name is sent unencrypted. This 
> isn’t really of much concern for mail, though.
>
> Of note, this thread predates the wide public availability of free 
> certificates. We already have logic that re-issues a certificate when domain 
> configurations change; in fact, the overhead of rebuilding Dovecot’s 
> configuration is part of what I’d like to minimize.

It also pre-dates some large mail services requiring SNI, mostly as a result
of this client support for SNI is much better now.

One benefit of doing this is that horizontal scaling can be done by moving
entire domains to another server and repointing DNS, that way neither a
protocol-level proxy nor client config changes are needed. It's not suitable
for every mail service but there are credible reasons to use SNI here.

Re: How to enable LDAP authentication for schema SSHA384

[Stuart Henderson]

On 2021-11-07, Ralph Seichter  wrote:
> * Alexander Dalloz:
>
>> Don't know about Ubuntu specifics [...]
>
> Thank you for the pointers. Am I right to interpret the Dovecot docs as
> stating that SSHA384 is not supported by the official packages, and that
> my only recourse might be building from the source code and adding some
> external code in the process?
>
> I do not remember encountering SSHA384 before, but the existing LDAP
> records use this schema for about half of a huge user base. Telling all
> affected users to change their passwords is not an option.

Assuming that SSHA384 is supported by your LDAP server, you could
perhaps use "auth_bind = yes" to have Dovecot attempt a bind with the
user-supplied password, rather than having Dovecot retrieve the hashed
password and validate it itself.

Re: Sync via ssh fails when ssl is active

[Stuart Henderson]

On 2022-01-20, Johan  wrote:
> I have computers at two different locations and one computer running 
> dovecot at each place. I sync my emails between these two servers using 
> ssh and I haven't had any problems with this lately until I upgraded 
> dovecot recently.
>
> I now get the following error at location "alfa" when trying to sync 
> with dovecot at location "delta"
>
> Jan 20 16:13:09 doveadm: Error: doveconf: Fatal: Error in configuration 
> file /etc/dovecot/conf.d/10-ssl.conf line 16: ssl_cert: Can't open file 
> /etc/letsencrypt/live/delta.oxyl.net/fullchain.pem: Permission denied

This is a problem that was introduced in 2.3.11 and fixed in 2.3.17.

Updating would be better, but as a workaround you can move the ssl_key
line to a separate config file, make it only readable by root, and use
e.g.

!include_try /etc/dovecot/ssl-keys.conf

to pull it in.

Re: Lucene support for FTS - EOL date.

[Stuart Henderson]

On 2022-02-05, Jacek Grabowski  wrote:
> Ok but I have to know the date (approximate) when support for lucene will
> be removed completely from dovecot.
> Does anyone know when this will happen? It is scheduled in some version in
> the future maybe?

Why not assume that it could be removed at the next release and make
plans to migrate to a maintained FTS engine? If dovecot-fts-lucene is
currently working for you then dovecot-fts-flatcurve might be a good
alternative. (Another option is to not update. You might think that's
a bad idea, but with fts-lucene you already on something which is
outdated so that isn't new).

Re: Sv: dovecot mailing list (this mailing list), DKIM, SPF and DMARC

[Stuart Henderson]

On 2022-02-10, dove...@ptld.com  wrote:
> It is possible for a mailing list to pass DMARC verification, but
> there doesn't seem to be a lot of motivation to put in the extra effort
> to make it work.

It is possible, but it breaks how many people expect mailing lists to work.

Re: Very slow mail download/notification with dovecot 2.2.33 and Thunderbird

[Stuart Henderson]

On 2020-02-11, ml_dove...@thorsten-reichelt.de 
 wrote:
> I know that there are many results if I search for "dovecot thunderbird
> very slow" on Google but none of them helped me with my problem. :(

Do you have imap compression enabled? I had some problems with that and
Thunderbird.

> I just don't know where to look for the cause right now, but I can
> provide configurations (like output of |doveadm config) |and some logfile=

Providing any non-default config is usually helpful.

Re: Dovecot v2.3.10 Released

[Stuart Henderson]

On 2020-03-06, Aki Tuomi  wrote:
> + Add tool for generating sysreport called dovecot-sysreport.
>=C2=A0 This generates a bundle of information usually needed for support
>=C2=A0 requests.

This goes to some lengths to remove passwords in dovecot config files, but
it includes userdb/passdb files in the archive which can include passwords
(possibly hashed, possibly not, either way still sensitive).

(Also it relies on GNU extensions to grep and tar - would it be worth
converting those parts to perl/python instead, because it already relies on
them in order to actually hide the passwords?)

Re: FTS-lucene errors : language not available for stemming

[Stuart Henderson]

On 2020-05-19, David Gessel  wrote:
> I'm getting some log errors with clucene that I am having no luck tracking 
> down on the interwebs.

This looks relevant:

https://www.mail-archive.com/dovecot@dovecot.org/msg66366.html

> I am considering switch to xapian (solr and java... pls noe) as the
> port is quite tempting from an ease of integration perspective, but the
> easiest solution would be to resolve these odd indexing errors.  Anyone
> have a clue?

dovecot-fts-xapian is easy to configure, but has a big downside compared
to solr in that the indexer runs as root.

Re: FTS-lucene errors : language not available for stemming

[Stuart Henderson]

On 2020/05/19 17:04, Aki Tuomi wrote:
> 
> On 19/05/2020 16:48 Stuart Henderson  wrote:
> 
> 
> On 2020-05-19, David Gessel  wrote:
> 
> I'm getting some log errors with clucene that I am having no luck 
> tracking down on the
> interwebs.
> 
> This looks relevant:
> 
> https://www.mail-archive.com/dovecot@dovecot.org/msg66366.html
> 
> 
> I am considering switch to xapian (solr and java... pls noe) as the
> port is quite tempting from an ease of integration perspective, but 
> the
> easiest solution would be to resolve these odd indexing errors.  
> Anyone
> have a clue?
> 
> dovecot-fts-xapian is easy to configure, but has a big downside compared
> to solr in that the indexer runs as root.
> 
> Dovecot indexer does not run as root.
> 
> ---
> Aki Tuomi
> 

It does in the not entirely uncommon case where you have setup
dovecot-fts-xapian, have multiple system users rather than a single
uid owning all mailboxes, and need to index all mailboxes.

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
44468 root   20   11M   18M sleep/6   netio 1:41 68.36% doveadm 
index -A *

With solr the indexing is done out-of-process and typically under a
safe uid.

Re: identify 143 vs 993 clients

[Stuart Henderson]

On 2020-05-26, mj  wrote:
> Hi,
>
> On 25/05/2020 23:04, Voytek wrote:
>> jumping here with a question, if I use 143 with STARTTLS, and, force
>> TLS/SSL in configuration, that's equivalent from security POV, isn't
>> it? and, same for 110 STARTTLS? Or am I missing something?
> Interesting point, after some googling, I think you are right, and as 
> long as we have set "disable_plaintext_auth = yes" (and we have that) we 
> should be fine keeping 143 open. Right?

In the case of 143, nothing stops the client *sending* a plaintext login
request. Login may be denied, but the password is already leaked. Also
if you have only the server side (not the client side) deny plaintext
logins, a MITM can just strip off the STARTSSL capability from the server
response.

In a setting where you want to protect the clients from accidentally
exposing secrets by misconfiguration, allowing only 993/995 (and 465 for
SMTP; 25/587 have the same problem) is the safe way.

Re: Plugin ABI compat between v2.3.8 and v2.3.9

[Stuart Henderson]

On 2020-06-15, Alexander Strasser  wrote:
> I had some imap crashes (sig11) starting at the end of 2019 after
> an upgrade of dovecot.
>
> I found out, that I didn't have any problems using version v2.3.8,
> but any version v2.3.9 and higher would trigger the crashes.
>
> After investigating more deeply and creating a core dump, I saw
> that the crash happened in an external plugin fetchmail_wakeup[1].
>
> After recompiling that plugin with up to date dovecot headers,
> I didn't get crashes anymore.
>
> So I suspect there were ABI incompatible changes and it was
> forgotten to bump the minimum Plugin-ABI version supported.

dovecot-2.3.8/configure
#define DOVECOT_ABI_VERSION "2.3.ABIv8($PACKAGE_VERSION)"

dovecot-2.3.9/configure
#define DOVECOT_ABI_VERSION "2.3.ABIv9($PACKAGE_VERSION)"

Did you disable version checking? (version_ignore = yes)

Re: 2.3.10.1 on OpenBSD

[Stuart Henderson]

On 2020-07-06, Rupert Gallagher  wrote:
> Both Dovecot and OpenDKIM packages on OpenBSD are rejecting
> connections because of CRYPTO, and they use libressl by default.

That's best reported with information (at least version numbers of
software involved, relevant logs, and info about which server is having
problems) to the package maintainer and/or libressl developers.

> I use
> openssl because libressl does not implement dane, so I am recompiling
> both to serve my use case, and sharing results along the way.

It is difficult to correctly build against openssl on a system where
the OS and all other packages use libressl. If you mix the two (i.e.
headers from libressl and library from openssl or vice-versa, or linking
against libraries that pull in "the other" library than you're using -
the obvious example in the case of Dovecot would be ldap/mariadb/pgsql
libraries) then you can expect it to fail, possibly in exciting ways.

Re: v2.2.26 release candidate released

[Stuart Henderson]

On 2016-10-19, Timo Sirainen  wrote:
> http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz
> http://dovecot.org/releases/2.2/rc/dovecot-2.2.26.rc1.tar.gz.sig
>
> There are quite a lot of changes since v2.2.25. Please try out this RC so we 
> can get a good and stable v2.2.26 out.

I'm seeing this on OpenBSD:

cc -DHAVE_CONFIG_H -I. -I../.. -I../../src/lib -I../../src/lib-test 
-I../../src/lib-settings -I../../src/lib-master -I../../src/lib-ssl-iostream 
-I/usr/local/include -std=gnu99 -O2 -pipe -Wall -W -Wmissing-prototypes 
-Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 
-Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -I/usr/include 
-MT ldap-search.lo -MD -MP -MF .deps/ldap-search.Tpo -c ldap-search.c -fPIC 
-DPIC -o .libs/ldap-search.o
ldap-search.c: In function 'ldap_search_send':
ldap-search.c:99: error: variable 'tv' has initializer but incomplete type

Fixed by adding "#include ".

Re: v2.2.26.0 released

[Stuart Henderson]

On 2016-11-02, Aki Tuomi  wrote:
> If the standard way works, I am happy to include the original patch I 
> sent, amended so that it checks for presence of LIBRESSL_VERSION_NUMBER. 
> If they keep this promise, then we should have no worries about things 
> breaking up.

Diff below is what I've added to OpenBSD ports.

The libressl API is not cast in stone, there's a possibility some
functions from newer OpenSSL might be added - in fact we already have
some like TLS_method. 0x2000L was specifically chosen to not
match up with anything OpenSSL had used because they aren't directly
comparable.

In general I think the best approach would be for feature checks, e.g.
in autoconf. (I wish there was some common m4 file shared between
projects that people could use for this..) In the absence of this,
it seems a better idea to check at the places where #ifdefs are done
rather than override OPENSSL_VERSION_NUMBER locally.

I don't think carrying patches like this separately is all that good an
idea - people may well compile things on their own and not know about
the problem. If the build fails that's not so bad, but the silent
miscompile we see here is pretty nasty.


--- src/lib-dcrypt/dcrypt-openssl.c.origWed Nov  2 12:11:31 2016
+++ src/lib-dcrypt/dcrypt-openssl.c Wed Nov  2 12:22:26 2016
@@ -67,7 +67,7 @@
   2key algo oid1symmetric algo namesalthash 
algoroundsE(RSA = i2d_PrivateKey, EC=Private Point)key id
 **/
 
-#if OPENSSL_VERSION_NUMBER < 0x1010L
+#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)
 #define EVP_PKEY_get0_EC_KEY(x) x->pkey.ec
 #define EVP_PKEY_get0_RSA(x) x->pkey.rsa
 #define OBJ_length(o) ((o)->length)
@@ -90,7 +90,7 @@ struct dcrypt_context_symmetric {
 struct dcrypt_context_hmac {
pool_t pool;
const EVP_MD *md;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
HMAC_CTX *ctx;
 #else
HMAC_CTX ctx;
@@ -427,7 +427,7 @@ static
 void dcrypt_openssl_ctx_hmac_destroy(struct dcrypt_context_hmac **ctx)
 {
pool_t pool = (*ctx)->pool;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
if ((*ctx)->ctx) HMAC_CTX_free((*ctx)->ctx);
 #else
HMAC_cleanup(&((*ctx)->ctx));
@@ -470,7 +470,7 @@ bool dcrypt_openssl_ctx_hmac_init(struct dcrypt_contex
 {
int ec;
i_assert(ctx->md != NULL);
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
ctx->ctx = HMAC_CTX_new();
if (ctx->ctx == NULL) return dcrypt_openssl_error(error_r);
ec = HMAC_Init_ex(ctx->ctx, ctx->key, ctx->klen, ctx->md, NULL);
@@ -484,7 +484,7 @@ static
 bool dcrypt_openssl_ctx_hmac_update(struct dcrypt_context_hmac *ctx, const 
unsigned char *data, size_t data_len, const char **error_r)
 {
int ec;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
ec = HMAC_Update(ctx->ctx, data, data_len);
 #else
ec = HMAC_Update(&(ctx->ctx), data, data_len);
@@ -498,7 +498,7 @@ bool dcrypt_openssl_ctx_hmac_final(struct dcrypt_conte
int ec;
unsigned char buf[HMAC_MAX_MD_CBLOCK];
unsigned int outl;
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
ec = HMAC_Final(ctx->ctx, buf, &outl);
HMAC_CTX_free(ctx->ctx);
ctx->ctx = NULL;
@@ -2133,7 +2133,7 @@ bool dcrypt_openssl_public_key_id_evp(EVP_PKEY *key, c
long len = BIO_get_mem_data(b, &ptr);
unsigned int hlen = sizeof(buf);
/* then hash it */
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
EVP_MD_CTX *ctx = EVP_MD_CTX_new();
 #else
EVP_MD_CTX *ctx = EVP_MD_CTX_create();
@@ -2147,7 +2147,7 @@ bool dcrypt_openssl_public_key_id_evp(EVP_PKEY *key, c
buffer_append(result, buf, hlen);
res = TRUE;
}
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
EVP_MD_CTX_free(ctx);
 #else
EVP_MD_CTX_destroy(ctx);
--- src/lib-ssl-iostream/dovecot-openssl-common.c.orig  Wed Nov  2 12:11:31 2016
+++ src/lib-ssl-iostream/dovecot-openssl-common.c   Wed Nov  2 12:21:04 2016
@@ -10,7 +10,7 @@
 static int openssl_init_refcount = 0;
 static ENGINE *dovecot_openssl_engine;
 
-#if OPENSSL_VERSION_NUMBER >= 0x1010L
+#if OPENSSL_VERSION_NUMBER >= 0x1010L && !defined(LIBRESSL_VERSION_NUMBER)
 static void *dovecot_openssl_malloc(size_t size, const char *u0 ATTR_UNUSED, 
int u1 ATTR_UNUSED)
 #else
 static void *dovecot_openssl_malloc(size_t size)
@@ -26,7 +26,7 @@ static void *dovecot_openssl_malloc(size_t size)
return mem;
 }
 
-#

Re: Problem with Let's Encrypt Certificate

[Stuart Henderson]

On 2017-02-19, KT Walrus  wrote:
>> That's one of the reasons I don't like Let's Encrypt, with one year
>> certs it is easier to look at the certs and see what is going to expire
>> in the coming month needing a new private key.
>
> I use dehydrated (with Cloudflare DNS challenges) and as far as I
> know, it seems to generate a new private key every time.

This is client-dependent, the CA doesn't care either way.

Re: Sieve not filtering

[Stuart Henderson]

On 2017-02-18, Ben  wrote:
>
>> What I did when encountering a similar issue was to take one of the messages 
>> from INBOX that should have been moved elsewhere and use sieve-test on it:
>>
>> sieve-test -Tlevel=matching  
>>
>> That generates a lot of output as it goes through every line of the sieve 
>> file and shows the actual values that are used for the tests.  However, it 
>> pointed out my problem quite clearly.
>>
>
> Thank you for this.
>
> Actually, after many hours of head-bashing, I discovered the problem.
>
> sieve doesn't work when you're just using telnet port 25 !
>
> I was doing :
> ehlo test
> mail from:sen...@example.com
> rcpt to:re...@example.com
> data
> Subject: hello world
> Hello World !
> .
>
> With the above, sieve was simply sending everything to INBOX
> 
> When I changed my methodology :
> ehlo test
> mail from:sen...@example.com
> rcpt to:re...@example.com
> data
> From:
> To:
> Subject: hello world
> Hello World !
> .
>
> It worked as expected.
>

The first one works as expected too; your rule used "address" so it
is correct that it didn't look at the envelope address. You want e.g. 

envelope "to" "f...@example.org"

Re: Possible to increase connection limit for one user only?

[Stuart Henderson]

On 2022-05-17, Kurt Fitzner  wrote:
> I run a medium-sized virtual domain email server for about 15 domains=2E  I=
>  also use it myself and have 3 or 4 devices using imap=2E   I am often usin=
> g a VPN to connect to my home network, which makes all my connections appea=
> r to come from one IP=2E
>
> I want to increase mail_max_userip_connections just for myself only so I'm=
>  not opening up my server to abuse=2E  Is this possible?

Simplest way is probably to add that IP to login_trusted_networks.

Re: Force TCP socket disconnect on imap login failure?

[Stuart Henderson]

On 2022-05-24, Hippo Man  wrote:
> * Hacker makes numerous login attempts one after the other with various
> passwords, and without disconnecting in between attempts. I've seen 10 and
> more of these repeated attempts rapidly during a single imap or pop3
> connection.

"numerous" and "rapidly" sounds wrong; between auth_failure_delay (in a single
connection) and the penalty mechanism for all connections from an IP address
(https://doc.dovecot.org/configuration_manual/authentication/auth_penalty/)
it should soon get beyond "rapidly".

Is there something in your config that disables this? Or is your idea of
"rapidly" just different to mine?

Re: Panic: file userdb-blocking with Dovecot 2.3.19

[Stuart Henderson]

On 2022-05-24, Niklas Meyer  wrote:
> since we´ve tested around with the new dovecot release in the mailcow 
> project we´ve came across a curious and new error with Dovecot:
>
> /auth: Panic: file userdb-blocking.c: line 124 
> (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL)/

This is fixed in https://github.com/dovecot/core/commit/30e69471792aec8

Re: Perl5 error in logs

[Stuart Henderson]

On 2022-07-07, @lbutlr  wrote:
> I am getting a lot of these in the logs:
>
>  dovecot[52816] imap: Error: Use of uninitialized value $ENV{"PATH"} in split 
> at /usr/local/lib/perl5/5.36/mach/File/Spec/Unix.pm line 256.
>
> FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC
>===>>> dovecot-2.3.19.1
>===>>> dovecot-pigeonhole-0.5.19
>===>>> perl5-5.36.0
>
> All packages ae up-to-date on the system.
>
> Other than the error there doesn’t seem to be any other effect/
>
> Ideas?

Since Dovecot doesn't use perl itself, this will be from whatever script
you are running from Dovecot (perhaps some external script triggered by
imapsieve for spam learning).

Re: Thunderbird can't connect to Dovecot (bad certificate: SSL alert number 42)

[Stuart Henderson]

On 2022-09-14, Goetz Schultz  wrote:
> I had the same issue on TB102. Self-Signed certificates rejected despite 
> having the CA installed correctly as authority. Turns out out that that 
> TB now wants extension "Subject Alt Names". Added that and all works 
> now. Seems another Google pressed issue being introduced (my Chromium 
> had same issues and rejected certs before I added SAN).

It's not just a "Google pressed issue".

The CA/Browser Forum baseline requirements say that certificates must
include subjectAlternativeName. This doesn't strictly apply to non-browser
applications but it does mean that all CA-issued certs can be relied upon
to have SAN.

RFC 6125 6.4.4 says that clients must not check CN if the identifiers
used in subjectAlternativeName are present. So for certs following the
baseline requirements, checking CN is redundant. It also says that
clients *may* check CN but it's not required.

There are differences in handling of name constraints between certs
using just CN and those using SAN. Name constraints don't really work
for certs using CN (by adding dc= components to the Subject, you can
comply with the directoryNameconstraints that apply to Subject
while providing a CN that is not in the expected domain). The dNSName
constraint applicable to SAN doesn't have this problem.

So there's a good reason to avoid using CN when checking the name: it
gives defence against a CA or sub-CA with a trusted but constrained root
certificate that goes rogue.

Practically this means you need to make sure that if you use self-
signed or internal CA certificates you include subjectAlternativeName
otherwise they won't work with some client software. If you use public
CA-signed certs you typically don't need to do this yourself because
the CA adds SAN if missing from the CSR (their only other option is
to reject issuance).

Re: Dovecot mail-crypt webmail can't read encrypted messages

[Stuart Henderson]

On 2022-10-11, Bernardo Reino  wrote:
> Please please stop top-posting. Makes a mess of everything!

I think everything that can be said in this thread, already has been said...

Re: The end of Dovecot Director?

[Stuart Henderson]

On 2022-10-24, Alessio Cecchi  wrote:
>
> Director is not only used by large companies but also in small 
> installations consisting of 2 servers and cannot be immediately replaced 
> with Nginx as it has to manage the user/backend association for POP, 
> IMAP, LMTP, Managesieve.

For the small multi-server installations I've done I have used ldap (though
another db would work) where a primary server is defined for each user.
The MTA does a lookup and uses the relevant host as destination for LMTP
delivery. For client connections, users can connect to any server; Dovecot
config uses proxy_maybe so if they hit the primary server for their mailbox
then it's served directly, and otherwise it's proxied. (And in my case
I care more about availability than splitting disk storage, so I replicate
in Dovecot). This doesn't use Director.

Isn't Director only really useful in the case where you have 2 or more servers
*and shared mailbox storage*, and you don't have a way to define a "primary"
server for the mailbox? I don't really see how it's useful for simpler configs.

Re: Corrupted sizes in cache once again

[Stuart Henderson]

On 2023-02-01, Tim Evers  wrote:
> I run a fairly large Dovecot Installation (around 100k mailboxes) on 
> several servers.
>
> gzip compression is on.
>
> Every once in a while I get the dreaded "cache corruption" messages in 
> the log:
>
> Error: Corrupted record in index cache file 
> /[redacted]/Maildir/dovecot.index.cache: UID 3868: Broken physical size 
> in mailbox INBOX: 
> read(zlib(/[redacted]/Maildir/cur/1674129792.M797543P21755.node2,S=8099,W=8276:2,))
>  
> failed: Cached message size smaller than expected (2877 < 8099, 
> box=INBOX, UID=3868)
>
> Error: Corrupted record in index cache file 
> /[redacted]/Maildir/dovecot.index.cache: UID 3875: Broken physical size 
> in mailbox INBOX: 
> read(zlib(/[redacted]/Maildir/cur/1674212201.M985809P29112.node2,S=13907,W=14121:2,))
>  
> failed: Cached message size smaller than expected (5533 < 8192, 
> box=INBOX, UID=3875)
>
> The first entry shows 2877 (size on disk) vs. 8099 (real size unzipped, 
> also in the filename: S=8099).
>
> The second entry shows 5533 (size on disk) vs. 8192 - this is not 
> correct in any way. Size on disk is 13907 as noted in the filename.
>
> Both mails were delivered trough LMTP and retrieved by the POP3 service.
>
> Anyone with an idea what might be happening here? I've read all 
> available info in the doc and in the previous discussions / bug reports, 
> but nothing seems to match my case. And where does that 8192 come from - 
> it looks suspicious?
>
> Version is 2.3.7.2 (Ubuntu 20.04)

2.3.7.2 is rather old now. There were definitely fixes regarding compression
around the 2.3.10-2.3.12 timeframe or thereabouts (I forget all the details
but it took a release or two before some remaining issues were sorted out
after changes in the area). I'd be looking to get it updated to a current
version first.

Re: Corrupted sizes in cache once again

[Stuart Henderson]

On 2023-02-02, Tim Evers  wrote:
>
> Am 02.02.23 um 16:23 schrieb Aki Tuomi:
>> For bug reports, we do ask that you try to reproduce it with 2.3.20 (current 
>> latest), you can get packages from https://repo.dovecot.org/ and would be 
>> nice if you can provide steps to reproduce this issue.
>>
>> Also please see https://www.dovecot.org/bugreport-mail/ if you have not yet.
>>
>> Aki
>
> This is not a bug report (yet) - I am asking for ideas to narrow down 
> the issue myself. I would not expect something this obvious and 
> prevalent being a bug in a 10+ years old subsystem (zlib).

Some of the errors seen that were fixed in the period that I mentioned
looked *exactly* like this.

Re: [OFF TOPIC] Re: Pigeonhole Sieve Vacation Reply-To peculiarity with inbound AWS-SES

[Stuart Henderson]

On 2023-02-10, Michael Peddemors  wrote:
> TOP POSTING for clarity
>
> I think this is getting off topic for the dovecot list.  Vacation 
> messaging is a complex topic, and for the record it does seem that the 
> way they are doing vacation messages could use improvement.
>
> This should NOT be sent as a BOUNCE <>, and it should NOT come from 
> MAILER-DAEMON, as it is actually from the person with the vacation message.

Pigeonhole is following RFC 3834 which sees it differently, in particular
the RFC tries to avoid anything which might trigger loops.

   Since in most cases it is not appropriate to respond to
   an automatic response, and the responder is not interested in
   delivery status messages, a MAIL FROM address of <> MAY be used for
   this purpose.  A MAIL FROM address which is specifically chosen for
   the purpose of sending automatic responses, and which will not
   automatically respond to any message sent to it, MAY be used instead
   of <>.

> It also should NOT have a precedence header of BULK.

   A response MAY include a Precedence field [I4.RFC2076] in order to
   discourage responses from some kinds of responders which predate this
   specification.  The field-body of the Precedence field MAY consist of
   the text "junk", "list", "bulk", or other text deemed appropriate by
   the responder.  Because the Precedence field is non-standard and its
   interpretation varies widely, the use of Precedence is not
   specifically recommended by this specification, nor does this
   specification recommend any particular value for that field.

>> The actual problem is that Pigeonhole responds to 
>> to=<010301863b0211fe-9416f5b2-7e18-4c03-a5e5-2204dd7946f8-000...@sa-east-1.amazonses.com>
>>  instead of to=.

Exactly as it should:

   In general, automatic responses SHOULD be sent to the Return-Path
   field if generated after delivery.  If the response is generated
   prior to delivery, the response SHOULD be sent to the reverse-path
   from the SMTP MAIL FROM command, or (in a non-SMTP system) to the
   envelope return address which serves as the destination for non-
   delivery reports.

Re: Mailing list changes.

[Stuart Henderson]

On 2023-04-12, dovecot--- via dovecot  wrote:
>> 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?
>
>
> Um okay, THIS email coming through the list did change the From: header to 
> the list address.
> I guess problem has been resolved since the last few list emails received.

It's fairly likely that From is rewritten in some cases but not others,
depending on DMARC settings for the sender's domain.

Don't rely on From for identifying the list, use List-ID instead.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Message searching in Dovecot

[Stuart Henderson]

On 2023-04-19, John Gateley via dovecot  wrote:
> The instructions here 
> https://doc.dovecot.org/configuration_manual/fts/solr/ are quite out of 
> date, they reference Debian 8 and 9 (current version 11), and Solr 7.7 
> (current version 9.2)

There are some posts on this list with updated config files, see e.g.
https://marc.info/?l=dovecot&m=167089659519693&w=2 or search the archives
for 'solr'.

>   * Is there a different tool than Solr I should be using for this?

dovecot-fts-flatcurve is much simpler to configure. Downside is that
the search and indexing is all done in-process so Dovecot processes can
grow quite large.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Remove attachments

[Stuart Henderson]

On 2023-06-03, John Stoffel  wrote:
>> "Oliver" == Oliver Glas  writes:
>
>> I am looking for a way to remove attachments, based on a condition.
>> Like attachments starting with "TimeReport" shall be removed, and
>> then the mail should be delivered, with all other attachments.
>
> This is not a solution that dovecat can work with.  You need to use a
> milter in your mailserver (like postfix) which can strip out mime
> attachements or do other modifications to an email before it's
> delivered to the mailbox.  
>
>> I did so far not find a solution to remove attachments.  Do I need a
>> plugin / extension  ? If so, how to implement and use that ?
>
> milters are what you want.  MIMEdefang is one.  

You can also do this by calling altermime from sieve with the
vnd.dovecot.filter extension from
https://doc.dovecot.org/configuration_manual/sieve/plugins/extprograms/


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Replication going away?

[Stuart Henderson]

On 2023-07-18, Gerald Galster  wrote:
> While I understand it takes effort to maintain the replication plugin, this 
> is especially problematic for small active/active high-availability 
> deployments.
> I guess there are lots of servers that use replication for just 50 or 100 
> mailboxes. Cloudstorage (like S3) would be overkill for these.

Even without active/active, it's super useful for the simple
active/backup configuration which I use on my personal mail server
setup (one colo box, one home server) and a small company mail
server; as such I'm pretty sad to see it go. Still, it is up
to OX where they want to put their resources.

I guess losing repl probably doesn't affect larger ISP type setups
so much; it seems a bit more common to use shared storage (e.g.
maildirs on an nfs appliance or similar) in those cases if they're
actually running their own storage.

> Do you provide dovecot pro subscriptions for such small deployments?

Unless I misunderstood the message (and I don't think I did), repl
was removed in pro too. (I don't expect that pro is available on my
usual choice of OS anyway..).


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Backing up m(d)box - rsync?

[Stuart Henderson]

On 2023-08-16, Gareth Evans  wrote:
>
> ... however it relies on doveadm which I don't have access to on a shared 
> host.
>
> I am looking into IMAP-based "doveadm backup" (ie running doveadm elsewhere) 
> but I fear this will require an admin username/password which wouldn't be 
> accessible on a shared host.

If you don't have admin access to add a master password configuration,
but do have the account passwords for the various you want to backup,
separate backup runs with either dovecot tools using imapc, or any
standard imap sync programs, are probably simplest. 

> I would be grateful if anyone can offer insight  re the rsync query.

I guess you'd probably need at least mmap_disable=yes on the server,
but I don't know enough about it to know whether that will be enough
by itself.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Can Dovecot Use Wildcard TLS Certificates?

[Stuart Henderson]

On 2023-09-27, dovecot--- via dovecot  wrote:
>> Quick Q: Can dovecot use wildcard TLS Certificates?
>> 
>> I'm having issues with a new dovecot/postfix stack set-up and I can't get 
>> mutt on the local box to connect via imap - its coming back with an SSL 
>> error, and as I'm using a wildcard cert for the domain I was wondering if 
>> that was my issue.
>> 
>> If dovecot can use wildcard certs then I'll look elsewhere in my 
>> troubleshooting.

Check that you have configured dovecot to serve any required
intermediate certs. If you post the hostname others can take a look
and let you know if that's the problem.

> I use wildcard certs on my dovecot.
>
>  ssl_cert =   ssl_key  = 
> I don't remember if it was dovecot specific, but i did have issues making the 
> cert with ONLY a wild card entry such as "*.example.com"
> I fixed the issue by creating the cert with two entries, one for 
> "example.com" and one for "*.example.com"

That is standard. A wildcard for *.example.com covers
.example.com but not ..example.com
or plain example.com.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Debian package for bookworm

[Stuart Henderson]

On 2023-10-14, Philip Iezzi via dovecot  wrote:
> Thanks for the clear statement. I thought, plans might have changed since 
> last June, as I didn't hear anything about upcoming Dovecot 2.4.
> Can we expect to see a release in the near future? No pressure! Please just 
> point me to some 2.4 roadmap or other information, if anything has been 
> published about 2.4

https://marc.info/?l=dovecot&m=169519369129344&w=2
"Since we are close to making new major release" (thread about the fix for
newer Linux kernels which is in the newer branch but not 2.3)

https://doc.dovecot.org/3.0/installation_guide/upgrading/from-2.3-to-3.0/
(info about deprecations/removals; refers to Pro 3.0 / community 2.4)


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot and SNI

[Stuart Henderson]

On 2024-03-12, steffan--- via dovecot  wrote:
> I have an old CentOS 7 server using dovecot 2.2.36  and OpenSSL 1.0.2k-fips=
>  that=92s been fine for quite some time. Recently I started getting complai=
> nts related to SNI.
>
> I test with this: openssl s_client -connect mail.domain.com:993 -crlf -quie=
> t
>
> On macOS using OpenSSL LibreSSL 3.3.6 I test and get the default dovecot do=
> main =93SomeWrongDomain.com=94 which causes issues.
>
> On Oracle Linux 9 using OpenSSL 3.0.7 I get the correct response for the do=
> main =93mail.domain.com=94

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.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

password schemes when crypt() has no DES

[Stuart Henderson]

https://github.com/dovecot/core/commit/54a1b3574acab5f778843f7f1e04d2d26d61a852
fixed a 'doveadm pw' crash "when trying to use CRYPT scheme when crypt() doesn't
support DES" by testing to see if crypt would generate a DES password and, if
not, disabling the scheme.

I'm using Dovecot on OpenBSD with bcrypt passwords stored in LDAP as
"{CRYPT}$2b$...". OpenLDAP is built with --enable-crypt which takes the
same approach as Dovecot of just passing to crypt(), so before the above
commit, both programs were able to authenticate.

(Changing the scheme value stored in the ldap passdb to BLF-CRYPT would
fix Dovecot but break things for other programs including OpenLDAP itself).

For now I went with a dirty patch to get things working again, does
anyone have an idea for a nicer fix?  Thanks.


--- src/auth/password-scheme-crypt.c.orig   Fri Jan  8 01:04:13 2016
+++ src/auth/password-scheme-crypt.cFri Jan  8 01:23:35 2016
@@ -111,7 +111,12 @@ static const struct {
const char *salt;
const char *expected;
 } sample[] = {
+#ifdef __OpenBSD__
+   { "08/15!test~4711", "$2a$04$0123456789abcdefABCDEF",
+ "$2a$04$0123456789abcdefABCDE.N.drYX5yIAL1LkTaaZotW3yI0hQhZru" },
+#else
{ "08/15!test~4711", "JB", "JBOZ0DgmtucwE" },
+#endif
{ "08/15!test~4711", "$2a$04$0123456789abcdefABCDEF",
  "$2a$04$0123456789abcdefABCDE.N.drYX5yIAL1LkTaaZotW3yI0hQhZru" },
{ "08/15!test~4711", "$5$rounds=1000$0123456789abcdef",
@@ -124,8 +129,13 @@ static const struct {
 
 /* keep in sync with the sample struct above */
 static const struct password_scheme crypt_schemes[] = {
+#ifdef __OpenBSD__
{ "CRYPT", PW_ENCODING_NONE, 0, crypt_verify,
+ crypt_generate_blowfisch },
+#else
+   { "CRYPT", PW_ENCODING_NONE, 0, crypt_verify,
  crypt_generate_des },
+#endif
{ "BLF-CRYPT", PW_ENCODING_NONE, 0, crypt_verify,
  crypt_generate_blowfisch },
{ "SHA256-CRYPT", PW_ENCODING_NONE, 0, crypt_verify,

Re: [Dovecot] Outlook (2010) -> Dovecot (IMAP) >10x slower with high network load and many folders

[Stuart Henderson]

On 2012-04-06, Thomas von Eyben  wrote:
> I am seeing a >10x as slow performance when trying to complete a
> "send/receive" from an Outlook 2010 client to Dovecot via IMAP, but
> only when the LAN is fully loaded with other traffic, EG file copying.
> It seems the problem is when outlook is trying to identify folders
> that have changed since last "send/receive" thus traversing the
> hierachy.

Not sure why it would only affect Outlook clients, but if your
switches are managed, you might like to check if flow control is
enabled and, if so, try disabling it.

[Dovecot] location of temporary files in deliver

[Stuart Henderson]

deliver has the following:

-- -- --
/* After buffer grows larger than this, create a temporary file to /tmp
   where to read the mail. */
#define MAIL_MAX_MEMORY_BUFFER (1024*128)

...

static struct istream *create_raw_stream(int fd, time_t *mtime_r)

...
input = i_stream_create_seekable(input_list, MAIL_MAX_MEMORY_BUFFER,
 "/tmp/dovecot.deliver."); 
-- -- --

On most of my systems, /tmp is relatively small (a few hundred MB, and sometimes
on ramdisk), and I like to use /var/tmp for larger temp space.

I just had a problem where I exceeded the space available in /tmp while
delivering a (multi recipient) message and had to modify the above line to
use an alternative location, and recompile.

Would it be appropriate to make this a configurable option instead?

Thanks.

Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
write_full(/tmp/dovecot.deliver) failed: No space left on device
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
write_full(/tmp/dovecot.deliver) failed: No space left on device
Feb  3 15:14:51 mh1-pl7 deliver(opx...@example.com): 
write_full(/tmp/dovecot.deliver) failed: No space left on device
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
write_full(/tmp/dovecot.deliver) failed: No space left on device
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
write_full(/tmp/dovecot.deliver) failed: No space left on device
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): stat(/tmp/Dovecot Delivery 
Mail) failed: No space left on device
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
msgid=<49885eb9.60...@example.com>: save failed to INBOX: BUG: Unknown internal 
error
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): sieve runtime error: Keep: 
Generic Error
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
sieve_execute_bytecode(/home/vmail/example.com/152/.dovecot.sievec) failed
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): stat(/tmp/Dovecot Delivery 
Mail) failed: No space left on device
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
msgid=<49885eb9.60...@example.com>: save failed to INBOX: BUG: Unknown internal 
error
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): sieve runtime error: Keep: 
Generic Error
Feb  3 15:14:51 mh1-pl7 deliver(1...@example.com): 
sieve_execute_bytecode(/home/vmail/example.com/125/.dovecot.sievec) failed

Re: [Dovecot] Removing Duplicates

[Stuart Henderson]

On 2010-03-14, Sabahattin Gucukoglu  wrote:
> The question is: does anybody know how I can find and remove duplicates, =
> either while injecting mail with IMAP, or afterward?  I can use tools to =
> find duplicate Message-IDs, but don't know of a way to remove duplicates =
> in mailboxes that are already imported as opposed to incoming mail.  =
> Perhaps there is a way to use the IMAP protocol for this?

This works fairly well: http://www.athensfbc.com/imap_tools/#delIMAPdups

Re: Need to authenticate Outlook and NTLM

[Stuart Henderson via dovecot]

On 2019-02-13, Mark Foley via dovecot  wrote:
> Is it possible that no one on this list is authenticating Outlook with 
> Dovecot and NTLM?

Yes, it's possible, the outdated instructions you found on the wiki
suggests it's an uncommon configiration.

No actual answers from me, but it might give you some clues:

> More on this ...
>
> I short-sheeted ntlm_auth to see what was being passed to it. It is getting 
> as arg1:
>
> --helper-protocol=squid-2.5-ntlmssp
>
> I tried running ntlm_auth at the command line as:
>
> ntlm_auth --username=user --password=password 
> --helper-protocol=squid-2.5-ntlmssp
>
> It did nothing, just hung there. The ntlm_auth man page says:
>
> --helper-protocol=PROTO
>   Operate as a stdio-based helper. Valid helper protocols are:

The squid auth helpers are stdio-based, they run in a loop, reading from
stdin, checking authentication, and return results on stdout. This avoids both
passing sensitive data on the command line (visible to ps, at least briefly)
and the need to keep forking and initialising a new process.

So it's normal that it would just sit waiting for input.

Dovecot is just reusing the same protocol that squid uses.

> After more searching I came across this post, 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774263
> which, in summary, said that ntlm_auth had to run as root. So, I added the 
> following to my
> dovecot config per that post's suggestion:
>
> service auth {
>   user = root
> }
>
> After restarting and trying again to connect from Outlook I got the message:
>
> auth: Info: ntlm(?,192.168.0.58,): user not authenticated: 
> NT_STATUS_NO_MEMORY

I don't know the full details of how samba/ntlm works, but this seems like
an error coming from the server you're attempting to authenticate against.
I think you should start debugging on the samba side - make sure tools
like wbinfo are working, if not then debug those with samba, then move
on to Dovecot after you have that working.

Re: Virus scan + removal on a mdbox mail storage

[Stuart Henderson via dovecot]

On 2019-02-22, David Pottage via dovecot  wrote:
> On 2019-02-21 22:14, Christoph Haas via dovecot wrote:
>
 NO! My mail storage is mdbox. And at the moment I have no intention 
 to
 convert it to Maildir!
>>> Could I ask why? maildir is a better storage format is almost every 
>>> respect.
>> 
>> well, I have a mailbox with about 50k emails ..., so one reason seems
>> to me better backup performance with mdbox, since there are much less
>> files to save.
>
> Assuming that you backup regularly then maildir is much better, because 
> new emails show up as new files, while old ones are left unchanged. This 
> means that an incremental backup only has to process new emails. With 
> mailbox, the file for the entire folder changes every time a new email 
> is delivered or the user edits any of them, so the whole mailbox needs 
> to be backed up again, resulting in far more I/O and time.

It sounds like perhaps you're confusing mdbox with mbox. mdbox uses
multiple files but not a single file per message. It is fairly sane for
backup handling - depending on how you set things up, you can have it
rotate after a fixed size, fixed time, or combination.

https://wiki2.dovecot.org/MailboxFormat/dbox

Re: Replication issue 2.3.7

[Stuart Henderson via dovecot]

On 2019-07-13, Reio Remma via dovecot  wrote:
> Hello!
>
> I noticed these in the logs since upgrading from 2.3.6. to 2.3.7:
>
> Jul 13 11:52:10 turin dovecot: doveadm: Error: 
> dsync-remote(r...@mrstuudio.ee): Error: 
> Exporting mailbox INBOX failed: Mailbox attribute 
> vendor/vendor.dovecot/pvt/server/sieve/files/MR lookup failed: Mailbox 
> attributes not enabled
> Jul 13 11:52:11 turin dovecot: doveadm: Error: 
> dsync-remote(r...@mrstuudio.ee): Error: 
> Exporting mailbox INBOX failed: Mailbox attribute 
> vendor/vendor.dovecot/pvt/server/sieve/files/MR lookup failed: Mailbox 
> attributes not enabled

Same here (in my case: on OpenBSD -current, mdbox, pigeonhole 0.5.7).
I have backed out to 2.3.6 + pigeonhole 0.5.6 and it's happy again.

Re: Replication issue 2.3.7

[Stuart Henderson via dovecot]

On 2019/07/16 19:46, Aki Tuomi wrote:
> 
> > On 16/07/2019 18:40 Stuart Henderson via dovecot  
> > wrote:
> > 
> >  
> > On 2019-07-13, Reio Remma via dovecot  wrote:
> > > Hello!
> > >
> > > I noticed these in the logs since upgrading from 2.3.6. to 2.3.7:
> > >
> > > Jul 13 11:52:10 turin dovecot: doveadm: Error: 
> > > dsync-remote(r...@mrstuudio.ee): Error: 
> > > Exporting mailbox INBOX failed: Mailbox attribute 
> > > vendor/vendor.dovecot/pvt/server/sieve/files/MR lookup failed: Mailbox 
> > > attributes not enabled
> > > Jul 13 11:52:11 turin dovecot: doveadm: Error: 
> > > dsync-remote(r...@mrstuudio.ee): Error: 
> > > Exporting mailbox INBOX failed: Mailbox attribute 
> > > vendor/vendor.dovecot/pvt/server/sieve/files/MR lookup failed: Mailbox 
> > > attributes not enabled
> > 
> > Same here (in my case: on OpenBSD -current, mdbox, pigeonhole 0.5.7).
> > I have backed out to 2.3.6 + pigeonhole 0.5.6 and it's happy again.
> 
> Instead of downgrading, you could've attempted
> 
> mail_attribute_dict = file:%h/dovecot-attributes
> 
> to enable mailbox attributes. This should fix sieve script replication too.
> 
> Aki

Perhaps, but when dealing with mailboxes out of sync between the two
replicated machines the first thought is to backout the change that
triggered the problem, rather than guess things that might help,
especially when they aren't mentioned in the release notes (actually
the only thing I find in either NEWS or ChangeLog relating to
attributes/metadata at all since the last release is adding methods
to access this via lua API?).

Re: Replication issue 2.3.7

[Stuart Henderson via dovecot]

On 2019-07-16, Stuart Henderson via dovecot  wrote:
> On 2019/07/16 19:46, Aki Tuomi wrote:
>> 
>> > On 16/07/2019 18:40 Stuart Henderson via dovecot  
>> > wrote:
>> > 
>> >  
>> > On 2019-07-13, Reio Remma via dovecot  wrote:
>> > > Hello!
>> > >
>> > > I noticed these in the logs since upgrading from 2.3.6. to 2.3.7:
>> > >
>> > > Jul 13 11:52:10 turin dovecot: doveadm: Error: 
>> > > dsync-remote(r...@mrstuudio.ee): Error: 
>> > > Exporting mailbox INBOX failed: Mailbox attribute 
>> > > vendor/vendor.dovecot/pvt/server/sieve/files/MR lookup failed: Mailbox 
>> > > attributes not enabled
>> > > Jul 13 11:52:11 turin dovecot: doveadm: Error: 
>> > > dsync-remote(r...@mrstuudio.ee): Error: 
>> > > Exporting mailbox INBOX failed: Mailbox attribute 
>> > > vendor/vendor.dovecot/pvt/server/sieve/files/MR lookup failed: Mailbox 
>> > > attributes not enabled
>> > 
>> > Same here (in my case: on OpenBSD -current, mdbox, pigeonhole 0.5.7).
>> > I have backed out to 2.3.6 + pigeonhole 0.5.6 and it's happy again.
>> 
>> Instead of downgrading, you could've attempted
>> 
>> mail_attribute_dict = file:%h/dovecot-attributes
>> 
>> to enable mailbox attributes. This should fix sieve script replication too.
>> 
>> Aki
>
> Perhaps, but when dealing with mailboxes out of sync between the two
> replicated machines the first thought is to backout the change that
> triggered the problem, rather than guess things that might help,
> especially when they aren't mentioned in the release notes (actually
> the only thing I find in either NEWS or ChangeLog relating to
> attributes/metadata at all since the last release is adding methods
> to access this via lua API?).
>
>

So after adding "mail_attribute_dict = file:%h/dovecot-attributes"
(alone, I have not configured to use the METADATA extension and the
file is not being created) and going back to 2.3.7, syncs are now
working and I see no more "lookup failed: Mailbox attributes not
enabled".

Prior to adding mail_attribute_dict, with a two server dsync setup,
new mail was syncing from A->B ok but new mail arriving on B didn't
sync to A.

I'm happy that things are now functioning ok on this setup but given
the limited information about what's happening and no information about
config changes needed for 2.3.6->2.3.7 I'm a bit twitchy about 2.3.7
in OS packages (I reverted it to 2.3.6 in OpenBSD after running into
the problem) so it would be nice to know a little more about what's
going on here.

Re: Dovecot for imap with LDAP

[Stuart Henderson via dovecot]

On 2019-08-09, Joseph Mays via dovecot  wrote:
> I am looking at replacing our creaky old courier-imap server, which takes 
> authentication and user info from an LDAP database, with dovecot imap. Any 
> comments on the wisdom of this choice of action, or anything I should know 
> about the setting up before starting to work on it?

Plenty of people have this type of setup, if you already know what you're
doing with LDAP from the existing installation you shouldn't have any problem
configuring it with Dovecot.

Re: [Sieve] Multiple email recipients, how?

[Stuart Henderson via dovecot]

On 2019-11-22, Ralph Seichter via dovecot  wrote:
> * Robert via dovecot:
>
>> We use a simple system for routing emails to different email users by 
>> postfixing the addresses with the actual user: xxxJohn@domain; 
>> yyyJohn@domain etc all will be delivered to user John.
>> (This way John can invent a new email address on-the-fly and that will 
>> be delivered to his email box.)

But now you can't have a username like "BigJohn@domain". To avoid this
problem a separator character of some sort (that isn't used in a normal
email address at your site) is really wanted.

> This seems like a strange way achieve flexible email addresses. Are you
> aware of sub-addressing? It has been around for ages, and is supported
> by Dovecot (and Gmail, incidentally).
>
> Imagine an existing email account . If alice wants to
> use a subadress, she signs up with , and Dovecot
> can automatically place incoming mail for that address into INBOX/foo
> (or just INBOX if INBOX/foo does not exist). Alice can use as many
> sub-adresses as she needs without anybody making config changes.

This method works well, but the separator character can be a problem.
"+" is traditional, but is widely blocked by website validators -
if you can use "-" or "." instead they're much more likely to be
accepted.

Re: MySQL connection with SSL

[Stuart Henderson via dovecot]

On 2024-05-16, Christopher Wensink via dovecot  wrote:
> See here for the documentation for dovecot:
>
> https://doc.dovecot.org/admin_manual/ssl/

Wrong bit of the manual. See the sample dovecot-sql.conf.ext or
https://doc.dovecot.org/configuration_manual/authentication/sql/#id10


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Expunging and deleting old messages - moving from cyrus-imap

[Stuart Henderson via dovecot]

On 2024-11-06, Nick Howitt via dovecot  wrote:
> I have just moved from cyrus-imap to dovecot.

Interesting, I'm considering going the other way when Dovecot 2.4 is
out and replication is lost ;-)


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Dovecot v2.4.0 released

[Stuart Henderson via dovecot]

On 2025-01-29, Timo Sirainen via dovecot  wrote:
> On 25. Jan 2025, at 22.29, Brad Smith via dovecot  wrote:
>> 
>> Test building 2.4 I see the last commit to the SSL code before the release 
>> went
>> out broke building with LibreSSL..
>> 
>> https://github.com/dovecot/core/commit/77d50a6b5e75796896e8e5b437783a99497908d9
>>  
>> 
>> 
>>   CC   iostream-openssl.lo
>> iostream-openssl.c:756:55: warning: unused parameter 'ssl_io' 
>> [-Wunused-parameter]
>> openssl_iostream_get_compression(struct ssl_iostream *ssl_io)
>>   ^
>> iostream-openssl.c:893:4: error: use of undeclared identifier 
>> 'SSL_OP_NO_RENEGOTIATION'
>> SSL_OP_NO_RENEGOTIATION)) {
>
> Well, the question is then whether LibreSSL does renegotiation always or 
> never with  entirely with LibreSSL + 

Re: Dovecot's default password storage scheme is not GDPR compliant

[Stuart Henderson via dovecot]

On 2025-02-12, Steven Varco via dovecot  wrote:
> Dovecot is an international software with many users living outside
> of the EU and are therefore not legislated to those braindead EU
> regulations.

btw, (like some of the USA's tax stuff) the UK and EU GDPR legislations
are extra-territorial. They apply if you provide services to users in
those areas, even if you're not in those areas yourself.

still, from what Rupert posted:

"the client sends the password in plain text (tls tunneled)"

...I find it hard to believe that using a TLS channel wouldn't be
considered good enough for sending login information. Surely a salted
hashed password database (who isn't using that anyway?) with
disable_plaintext_auth would be acceptable.

(If you want to open a can of worms, consider the contents of the emails
themselves, which are often much more sensitive than the passwords...)


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Bug: dovecot 2.3.21.1 fails to build with recent ICU

[Stuart Henderson via dovecot]

On 2025-03-29, Marcel Telka via dovecot  wrote:
> Hi,
>
> dovecot 2.3.21.1 fails to build with ICU 77.  There are also reports it does
> not build with ICU 76 for the same reason:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=284832
>
> There is no issue when built with ICU 75.
>
> The failure is this:
>
> /bin/bash ../../libtool  --tag=CC   --mode=link /usr/gcc/14/bin/gcc  
> -std=gnu99 -m64 -O3  -Wno-incompatible-pointer-types -fstack-protector-strong 
> -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -mfunction-return=keep 
> -mindirect-branch=keep -Wall -W -Wmissing-prototypes -Wmissing-declarations 
> -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast 
> -fno-builtin-strftime -Wstrict-aliasing=2 -I/usr/openssl/3/include   
> -no-undefined -m64  -o test-fts-icu test-fts-icu.o fts-icu.lo -licui18n 
> ../lib-test/libtest.la ../lib/liblib.la -lsocket -lnsl  -lsendfile
> libtool: link: /usr/gcc/14/bin/gcc -std=gnu99 -m64 -O3 
> -Wno-incompatible-pointer-types -fstack-protector-strong -U_FORTIFY_SOURCE 
> -D_FORTIFY_SOURCE=2 -mfunction-return=keep -mindirect-branch=keep -Wall -W 
> -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts 
> -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 
> -I/usr/openssl/3/include -m64 -o test-fts-icu test-fts-icu.o .libs/fts-icu.o  
> -licui18n ../lib-test/.libs/libtest.a ../lib/.libs/liblib.a -lsocket -lnsl 
> -lsendfile
> Undefined   first referenced
>  symbol in file
> ucasemap_utf8ToLower_77 .libs/fts-icu.o  (symbol belongs to 
> implicit dependency /usr/lib/amd64/libicuuc.so.77)
..
> The workaround is easy: to add -licuuc to LDFLAGS, however it would be great 
> if
> dovecot builds without any workarounds needed.

FWIW, 2.3.21.1 builds on OpenBSD with ICU 76.1 enabled without extra -l.
I haven't tried with ICU 77 yet.

(2.4 is no good for me until I can figure out a way to replace the lost
functionality).

___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org

Re: Android mail client capable of utilizing FTS?

[Stuart Henderson via dovecot]

On 2025-04-20, Alexander Skwar via dovecot  wrote:
> I enabled FTS Full Text Search using Tika in dovecot and have all the emai=
> ls now reindexed=2E Using either "IMAP by hand" (ie via telnet or openssl s=
> _client), SOGo webmail, or Thunderbird on macOS, I can search for and also =
> find emails based on text which is only in a PDF attachment=2E
>
> Using Thunderbird or the now dead k-9, I'm not finding anything=2E
>
> Can someone maybe suggest an email client for Android which is able to fin=
> d emails based on text in FTS? Technically, I guess it should do a "search =
> TEXT "foo bar"" query=2E

I'm using aquamail which does FTS, I would expect fairemail to do so too.


___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org