Re: [ext] Re: The future of SIS

2023-11-02 Thread Ralf Hildebrandt via dovecot
* Pedro Ribeiro via dovecot :
> Hello everyone!
> I'm reviving the topic just to add that after reconstructing our storage with
> SIS disabled the occupied space increased from 5.3TB to 9.6TB, almost 
> doubling!
> It's a feature promoting storage efficiency, I think it demands some
> ponderation the advantages of keeping or improving the module.

Amen to that. I think the deduplication is a useful, storage efficient
way -- especially in large environments with lots of users (who get
the same mails :) )

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de


smime.p7s
Description: S/MIME cryptographic signature
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org


Re: [ext] dovecot 2.0 supports EC private key?

2023-10-24 Thread Ralf Hildebrandt via dovecot
* Marc :
> 
> Does dovecot 2.0 supports EC private key?

Yes:

# Certbot RSA
ssl_cert = https://www.charite.de

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


How do I search for "greetings of the day"

2019-10-29 Thread Ralf Hildebrandt via dovecot
My users say that "greetings of the day" occurs in academic spam a lot.
Since I don't trust my users, I opted to verify this bold claim.

But how do I search for a sequence of multiple words?

doveadm import -u restore@backup.invalid mdbox:/home/copymail/mdbox "" mailbox 
INBOX BODY "Greetings of the day"
doveadm import -u restore@backup.invalid mdbox:/home/copymail/mdbox "" mailbox 
INBOX TEXT "Greetings of the day"
(what's the difference betweeen BODY and TEXT?)

Is it even possible, given that "the" and "of" are probably stop words?
-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-16 Thread Ralf Hildebrandt via dovecot
* Aki Tuomi via dovecot :

> 2.3.7 does not generate DH keys. It's been removed since 2.3.0

Yes, it was the only periodic process I could think/knew of.

> Is it possible for you to track and find out which process is causing the 
> peak?

Will try. Next hour :)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-16 Thread Ralf Hildebrandt via dovecot
* Ralf Hildebrandt via dovecot :
> * Timo Sirainen :
> 
> > > BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from 
> > > back in July.
> > 
> > Fixed by 
> > https://github.com/dovecot/core/commit/5e9e09a041b318025fd52db2df25052b60d0fc98
> >  and will be in the soon-to-be-released v2.3.8.
> 
> I stopped 2.3.7, copied over the index files from the ramdisk into
> the physical "realm" and restarted with a fresh 2.3.8. It probably
> takes a few days to be absolutely sure.

So, in general the performance issues are gone.

But... 

I'm seeing odd hourly spikes almost every hour, on the hour.
You might say: Well yes, that's a cronjob sending lots of mails. But
it isn't. There's not more or less mail coming in at that very moment.

I suspect something in dovecot running every hour (DH key regeneration?)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-08 Thread Ralf Hildebrandt via dovecot
* Timo Sirainen :

> > BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from 
> > back in July.
> 
> Fixed by 
> https://github.com/dovecot/core/commit/5e9e09a041b318025fd52db2df25052b60d0fc98
>  and will be in the soon-to-be-released v2.3.8.

I stopped 2.3.7, copied over the index files from the ramdisk into
the physical "realm" and restarted with a fresh 2.3.8. It probably
takes a few days to be absolutely sure.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-07 Thread Ralf Hildebrandt via dovecot
* Timo Sirainen :

> >> But why is that? Why would the index file be updated so often?
> > 
> > BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from 
> > back in July.
> 
> Fixed by 
> https://github.com/dovecot/core/commit/5e9e09a041b318025fd52db2df25052b60d0fc98
>  
> 
>  and will be in the soon-to-be-released v2.3.8.

Thanks. I will test this (once it's been released) by moving the index files 
back to
conventional storage. 

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] Re: dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-01 Thread Ralf Hildebrandt via dovecot
> > This command quickly pointed to 
> > ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp
> > That file was written excessively. 
> 

> Was it one user's dovecot.index.tmp or for a lot of users?

There's just one user. All mail goes to one mailbox.

> This
> means that dovecot.index is being rewritten, which should happen only
> once in a while, but now it sounds like it's happening maybe for every
> mail delivery.

Yes, it seems to be that way.

> If it's still happening, could you send me one folder's
> dovecot.index and dovecot.index.log files? (They don't contain
> anything sensitive other than maybe message flags.)

I can send the files.

> > This is dovecot 2.3.7.2-1~bionic
> 
> So you had been running this version already for a while, and then it just 
> suddenly started getting slow?

Yes. Initially I threw away the whole mailbox after it got slow, but
after a few days the performance started to degrade. Admittedly, it
contains a lot of mails :)

> I tried to reproduce this with imaptest and Dovecot that is patched
> to log when dovecot.index is being rewritten, but there doesn't seem
> to be any difference with v2.2.36, v2.3.7 or git master.
 
-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-01 Thread Ralf Hildebrandt via dovecot
* Ralf Hildebrandt via dovecot :

> But why is that? Why would the index file be updated so often?

BTW: This post is a followup to my "2.3.7 slower than 2.3.6?" post from back in 
July.


dovecot 2.3.7.2-1~bionic: Performance issues caused by excessive IO to ~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp

2019-10-01 Thread Ralf Hildebrandt via dovecot
I set up system copying all mails to a backup system.

This used to work without a hitch - now in the last few days mails
would pile up in the Postfix Queue, waiting to be delivered using the
lmtp transport into dovecot.

So dovecot was being slow, but why? After all, nothing changed.

After reading some articles on stackoverflow I found a way of finding
out which file gets the most IO:

% sysdig -c topfiles_bytes;

This command quickly pointed to 
~/mdbox/mailboxes/INBOX/dbox-Mails/dovecot.index.tmp
That file was written excessively. 

I then put ~/mdbox/mailboxes/INBOX/dbox-Mails/ into tmpfs and alas, the queue 
would drain quickly.

But why is that? Why would the index file be updated so often?

This is dovecot 2.3.7.2-1~bionic

# 2.3.7.2 (3c910f64b): /etc/dovecot/dovecot.conf
# OS: Linux 5.0.0-29-generic x86_64 Ubuntu 18.04.3 LTS 
default_vsz_limit = 2 G
lmtp_user_concurrency_limit = 1
mail_attachment_dir = /home/copymail/attachments
mail_attachment_hash = %{sha256}
mail_fsync = never
mail_location = mdbox:~/mdbox
mail_plugins = zlib fts fts_lucene
mdbox_rotate_size = 128 M
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
special_use = \Trash
  }
  prefix = 
}
passdb {
  args = username_format=%u /etc/dovecot/passwd
  driver = passwd-file
}
plugin {
  fts = lucene
  fts_languages = de,en
  fts_lucene = whitespace_chars=@.
}
protocols = " imap lmtp"
service imap-login {
  inet_listener imap {
address = 127.0.0.1
port = 143
  }
  inet_listener imaps {
port = 993
ssl = yes
  }
}
service lmtp {
  inet_listener lmtp {
  address = 10.0.5.208
port = 1025
  }
  process_min_avail = 5
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
  }
}
ssl_ca = /etc/ssl/certs/ca-certificates.crt
ssl_cert = https://www.charite.de



sis-queue: Parent filesystem not given as parameter

2019-09-26 Thread Ralf Hildebrandt via dovecot
I tried to change:
mail_attachment_fs = sis posix
to
mail_attachment_fs = sis-queue posix

and immediately failed with:

Failed to initialize user: Namespace '': mdbox: mail_attachment_fs: sis-queue: 
Parent filesystem not given as parameter

Where do I specify the "Parent filesystem"?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] 2.3.7 slower than 2.3.6?

2019-07-17 Thread Ralf Hildebrandt via dovecot
> > All of the data is an /dev/sda1
> 
> What filesystem is this?

ext4
 
> I did a bunch of testing, and after initially thinking I saw an
> increase it was just due to bad testing because the new TCP_NODELAY
> changes allowed imaptest to do more work. So I can't see that there is
> any disk IO difference.
> 
> There are a few intentional changes to lib-index and also mdbox
> code. One of those is that dovecot.index.cache files are being
> recreated more often now. In some cases they were wasting a lot of
> disk space because expunged mails hadn't been removed from them. I
> guess it's a possibility that all the disk IO was because in your
> system Dovecot started recreating all those files at the same time.
> Maybe you could try upgrading again during slower hours and see if the
> disk IO normalizes after a while?

Still running 2.3.7. 

Looking at the disk IO graphs today's IO usage looks OK!

I restarted dovecot yesterday after fixing the FTS settings:
Jul 16 10:14:45 mail-cbf dovecot: master: Dovecot v2.3.7 (494d20bdc) starting 
up for imap, lmtp (core dumps disabled)

after that I saw quite a bit of IO on sda1 (a bit of data read, lot of write),
which subsided at11:30

After that diskio was low, up to the present day.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] 2.3.7 slower than 2.3.6?

2019-07-16 Thread Ralf Hildebrandt via dovecot
* Timo Sirainen via dovecot :

> > And alas, I had a look at the monitoring and found that disk IO has
> > increase A LOT after the update: 
> > https://www.arschkrebs.de/images/dovecot-disk-io-increase.png
> > 
> > I zoomed in and found that the sudden increace in IO coincides with
> > the update to 2.3.7 (14:35): 
> > https://www.arschkrebs.de/images/dovecot-io-2.png 
> > 
> 

> Do the different disks have different kinds of data? 

All of the data is an /dev/sda1

> Like you seem to be using external attachments and fts? 

Jup, using that, but on one disk

> Also your doveconf -n
> doesn't show what fts backend you're using. Or is it just
> half-configured and not really used?

I used to use lucene, but then I had issues building it
and commented it out. 

Looking now, it turns out that your packages come with lucene support...
Reenabling:

mail_plugins = zlib fts fts_lucene

...

plugin {
  fts = lucene
  fts_autoindex = yes
  fts_languages = de,en
  fts_lucene = whitespace_chars=@.
  zlib_save = gz
  zlib_save_level = 5
}



-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] 2.3.7 slower than 2.3.6?

2019-07-15 Thread Ralf Hildebrandt via dovecot
* Ralf Hildebrandt via dovecot :
> We're using dovecot (via LMTP) as a backup for all incoming mail.
> 
> I upgraded from 2.3.6 to 2.3.7 on the 12th:
> 2019-07-12 14:35:44 upgrade dovecot-imapd:amd64 2:2.3.6-2~bionic 
> 2:2.3.7-8~bionic
> 
> and it seems that 2.3.7 is slower than 2.3.6 -- mail to the backup
> IMAP box is suddenly taking quite some time to get delivered and is piling up
> in the queue.

And alas, I had a look at the monitoring and found that disk IO has
increase A LOT after the update: 
https://www.arschkrebs.de/images/dovecot-disk-io-increase.png

I zoomed in and found that the sudden increace in IO coincides with
the update to 2.3.7 (14:35): https://www.arschkrebs.de/images/dovecot-io-2.png

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



2.3.7 slower than 2.3.6?

2019-07-15 Thread Ralf Hildebrandt via dovecot
We're using dovecot (via LMTP) as a backup for all incoming mail.

I upgraded from 2.3.6 to 2.3.7 on the 12th:
2019-07-12 14:35:44 upgrade dovecot-imapd:amd64 2:2.3.6-2~bionic 
2:2.3.7-8~bionic

and it seems that 2.3.7 is slower than 2.3.6 -- mail to the backup
IMAP box is suddenly taking quite some time to get delivered and is piling up
in the queue.

doveconf -n:


default_vsz_limit = 2 G
lmtp_user_concurrency_limit = 1
mail_attachment_dir = /home/copymail/attachments
mail_fsync = never
mail_location = mdbox:~/mdbox
mail_plugins = zlib fts
mdbox_rotate_size = 128 M
... namespaces ...
plugin {
  fts_autoindex = yes
  fts_languages = de,en
  zlib_save = gz
  zlib_save_level = 5
}
protocols = " imap lmtp"
userdb {
  args = username_format=%u /etc/dovecot/passwd
  driver = passwd-file
}
protocol lmtp {
  mail_plugins = zlib fts
}
  

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] Re: Panic: file mail-index-util.c: line 10 (mail_index_uint32_to_offset): assertion failed: (offset < 0x40000000)

2019-05-24 Thread Ralf Hildebrandt via dovecot
* Aki Tuomi via dovecot :
> Known issue when folder cache is too big. Try rm -rf dovecot.index.cache
> for the folder.

-rw--- 1 mail mail 1746959712 May 24 14:37 dovecot.index.cache

yes, it is quite big :) 1.746.959.712

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Panic: file mail-index-util.c: line 10 (mail_index_uint32_to_offset): assertion failed: (offset < 0x40000000)

2019-05-24 Thread Ralf Hildebrandt via dovecot
I'm encountering a crash which this command:

% doveadm import -u restore@backup.invalid mdbox:/home/copymail2/mdbox '' 
mailbox INBOX header X-Spam Yes SAVEDBEFORE 2019-05-23

doveadm(restore@backup.invalid): Panic: file mail-index-util.c: line 10 
(mail_index_uint32_to_offset): assertion failed: (offset < 0x4000)
doveadm(restore@backup.invalid): Error: Raw backtrace:
/usr/lib/dovecot/libdovecot.so.0(+0xd9f9e) [0x7fbc52ba7f9e] ->
/usr/lib/dovecot/libdovecot.so.0(+0xd9fe1) [0x7fbc52ba7fe1] ->
/usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7fbc52b0cc54] ->
/usr/lib/dovecot/libdovecot-storage.so.0(mail_index_uint32_to_offset+0x78)[0x7fbc52f525e8]
 ->
/usr/lib/dovecot/libdovecot-storage.so.0(mail_cache_add+0x83b)[0x7fbc52f3ac2b] 
->
/usr/lib/dovecot/libdovecot-storage.so.0(index_mail_parse_header+0x449)[0x7fbc52f1c969]
 -> 
/usr/lib/dovecot/libdovecot.so.0(+0xb6af9) [0x7fbc52b84af9] ->
/usr/lib/dovecot/libdovecot.so.0(i_stream_read_memarea+0x7a) [0x7fbc52bb531a] ->
/usr/lib/dovecot/libdovecot.so.0(i_stream_read+0x2f) [0x7fbc52bb565f] ->
/usr/lib/dovecot/libdovecot.so.0(i_stream_read_data+0x3d)[0x7fbc52bb604d] ->
/usr/lib/dovecot/libdovecot.so.0(message_parse_header_next+0x68)[0x7fbc52b8b3f8]
 ->
/usr/lib/dovecot/libdovecot.so.0(message_parse_header+0x52)[0x7fbc52b8bdd2] ->
/usr/lib/dovecot/libdovecot-storage.so.0(+0xcadae) [0x7fbc52f26dae] ->
/usr/lib/dovecot/libdovecot-storage.so.0(+0xcc0ac) [0x7fbc52f280ac] ->
/usr/lib/dovecot/libdovecot-storage.so.0(index_storage_search_next_nonblock+0x11d)[0x7fbc52f288bd]
 ->
/usr/lib/dovecot/libdovecot-storage.so.0(mailbox_search_next_nonblock+0x28)[0x7fbc52ea92e8]
 ->
/usr/lib/dovecot/libdovecot-storage.so.0(mailbox_search_next+0x3d)[0x7fbc52ea934d]
 -> 
doveadm(+0x31443) [0x5635b4760443] -> 
doveadm(+0x2bdb1) [0x5635b475adb1] ->
doveadm(+0x2caf9) [0x5635b475baf9] ->
doveadm(doveadm_cmd_ver2_to_mail_cmd_wrapper+0x20e) [0x5635b475c9ce] -> 
doveadm(doveadm_cmd_run_ver2+0x55e) [0x5635b476db7e] ->
doveadm(doveadm_cmd_try_run_ver2+0x37) [0x5635b476dbd7] ->
doveadm(main+0x1d1) [0x5635b474aec1] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)
[0x7fbc5210fb97] -> doveadm(_start+0x2a) [0x5635b474b39a]


Version info:

ii  dovecot-core  2:2.3.6-2~bionic  amd64secure POP3/IMAP server - 
core files
ii  dovecot-dbg   2:2.3.6-2~bionic  amd64secure POP3/IMAP server - 
debug symbols
ii  dovecot-imapd 2:2.3.6-2~bionic  amd64secure POP3/IMAP server - 
IMAP daemon
ii  dovecot-lmtpd 2:2.3.6-2~bionic  amd64secure POP3/IMAP server - 
LMTP server

Backtrace:

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x768fa801 in __GI_abort () at abort.c:79
#2  0x77373f51 in default_fatal_finish (status=0, type=LOG_TYPE_PANIC) 
at failures.c:459
#3  fatal_handler_real (ctx=, format=, 
args=) at failures.c:471
#4  0x77373fe1 in default_fatal_handler (ctx=, 
format=, args=) at failures.c:479
#5  0x772d8c54 in i_panic (format=format@entry=0x7772e440 "file %s: 
line %d (%s): assertion failed: (%s)") at failures.c:523
#6  0x7771e5e8 in mail_index_uint32_to_offset (offset=) 
at mail-index-util.c:10
#7  0x77706c2b in mail_cache_header_fields_write (ctx=0x5583d960, 
buffer=, buffer=) at mail-cache-transaction.c:609
#8  mail_cache_header_add_field (field_idx=15, ctx=0x5583d960) at 
mail-cache-transaction.c:690
#9  mail_cache_add (ctx=0x5583d960, seq=1, field_idx=field_idx@entry=15, 
data=0x7773ba56, data_size=0) at mail-cache-transaction.c:739
#10 0x776eafdc in index_mail_cache_add_idx 
(mail=mail@entry=0x5583e2f8, field_idx=field_idx@entry=15, 
data=data@entry=0x7773ba56, data_size=data_size@entry=0) at index-mail.c:621
#11 0x776e8969 in index_mail_parse_header_finish (mail=) 
at index-mail-headers.c:132
#12 index_mail_parse_header (part=, hdr=, 
mail=) at index-mail-headers.c:312
#13 0x77350af9 in read_header (mstream=0x5584b7f0) at 
istream-header-filter.c:357
#14 i_stream_header_filter_read (stream=0x5584b7f0) at 
istream-header-filter.c:447
#15 0x7738131a in i_stream_read_memarea 
(stream=stream@entry=0x5584b870) at istream.c:313
#16 0x7738165f in i_stream_read (stream=stream@entry=0x5584b870) at 
istream.c:271
#17 0x7738204d in i_stream_read_data (stream=0x5584b870, 
data_r=data_r@entry=0x7fffdbe8, size_r=size_r@entry=0x7fffdbf0, 
threshold=threshold@entry=1) at istream.c:745
#18 0x773573f8 in i_stream_read_bytes (wanted=2, size_r=0x7fffdbf0, 
data_r=0x7fffdbe8, stream=) at ../../src/lib/istream.h:217
#19 message_parse_header_next (ctx=0x5584ca70, 
hdr_r=hdr_r@entry=0x7fffdc50) at message-header-parser.c:85
#20 0x77357dd2 in message_parse_header 

Re: [ext] Dovecot Wiki: Please disable edit on double click

2019-03-20 Thread Ralf Hildebrandt via dovecot
* Michael Goth via dovecot :

> could you maybe disable the 'edit on doubleclick' feature on
> wiki2.dovecot.org?
> 
> Everytime I try to select a word by double clicking on it, I end up in
> editing mode. It's just a minor thing, but maybe I'm not the only one who's
> annoyed by this ;)

Amen to that. I never bothered to ask, but it annoys the shit out of me!

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] Re: expunge not removing attachments?

2019-02-12 Thread Ralf Hildebrandt via dovecot
* @lbutlr via dovecot :
 
> I had problems with this a few years ago, and resorted to simply using find 
> to remove the files from the file system 
> 
> /usr/bin/find /usr/local/virtual/*/.Junk*/{cur,new} -type f -mtime +7 -name 
> “*=*" -delete 2> /dev/null
> /usr/bin/find /usr/local/virtual/*/.Trash/{cur,new} -type f -mtime +7 -name 
> “*=*" -delete 2> /dev/null

I'm not using Maildir. I suspect the SIS is broken somehow.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de



Re: [ext] expunge not removing attachments?

2019-02-12 Thread Ralf Hildebrandt via dovecot
* Ralf Hildebrandt :
> I have a large mail backup folder backup@backup.invalid; I'm cleaning
> up daily like this:
> 
> infimum=`date -d "-4 day" +"%Y-%m-%d"`
> doveadm expunge -u backup@backup.invalid mailbox INBOX SAVEDBEFORE $infimum 
> doveadm purge   -u backup@backup.invalid
> 
> yet I see this:
> 
> # find attachments/ -type f -ctime +5 | wc -l
> 7522
> # find attachments/ -type f | wc -l
> 127579
> 
> # find attachments/ -type f -mtime +5 | wc -l
> 14361
> # find attachments/ -type f | wc -l
> 127793
> 
> About 5.9% of the files in attachments and below are older than 5 days.
> Why? Is that normal?
> 
> using dovecot 2:2.3.1-1 from the official repos.

I retried this today (2:2.3.4.1-1~bionic):

# find attachments/ -type f -ctime +5 | wc -l
193121
# find attachments/ -type f | wc -l
301885

193121 of 301885 (64%) are older (ctime) than 5 days, although I just purged 
everything older than 4 days?


# /home/copymail# find attachments/ -type f -mtime +5 | wc -l
201629
# /home/copymail# find attachments/ -type f | wc -l
301900

201629 of 301900 (66.7%) files are modified (mtime) more than 5 days ago, 
although I just purged everything older than 4 days?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de