- dovecot - dovecot.org

Question about doveadm altmove
by María Arrea 05 Apr '21

05 Apr '21

4 4

failed to compile a sieve script with optional include
by André Rodier 05 Apr '21

05 Apr '21

Hi, I am trying to compile the following sieve script: ----------------------------- require [ "variables", "include", "relational", "imapsieve" ]; global "importing"; include :personal :optional "pre-sent-checks"; if string :count "eq" "${importing}" "1" { keep; stop; } ----------------------------- But I have this error: > sent-checks: line 15: error: include: personal location for included > script `pre-sent-checks' is unavailable (contact system administrator > for more information). > sent-checks: error: validation failed. > sievec(root): Fatal: failed to compile sieve script 'sent- checks.sieve' What should I do to compile a script with an optional user script, please ? Thanks

1 1

Mass Stripping Attachments by Directory, Age, Size
by Plutocrat 05 Apr '21

05 Apr '21

Hi, I've been looking around for a solution to this problem. I want to prune down the attachments on a server before a migration. Some of the emails are 7 years old and have 40Mb attachments, so this seems like a good opportunity to rationalize things. So perhaps I'd like to "Remove all attachments from emails older than 2 years, in the .Sent directory", or "Attachments over 10Mb anywhere in the mail tree" I've found the strip_attachments.pl script here <https://fossies.org/linux/Mail-Box/examples/strip-attachments.pl> which works fine on mbox (as tested on my local Thunderbird mboxes), but not on maildir which is on the dovecot server. My Perl isn't strong enough to re-purpose it. I've looked at ripmime and mpack/munpack, and although they seem like useful tools to do the job of deconstructing the mail into its constituent parts, it doesn't seem to help in re-building the email. I think they could be used with a bit of study into mail MIME structure, and used with a helper script. So before I take a deep dive into scripting my own solution, I just wanted to check if anyone else on the list has been through this and has some resources or pointers they can share, or maybe even someone to tell me "Duh, you can do it with doveadm of course". P.

5 8

thunderbird copy old messages from other dirs
by Brian 05 Apr '21

05 Apr '21

Is there a known documented way to copy messages from backup folders into the cur folder and have them not make a mess of the dates. What I see is if I copy several year old messages to the cur folder on an ubuntu box the massages when viewed on an android phone appear out of order. I tried deleting the dovecot index and cache files and restarting the service, I also tried running these 2 scripts I found. I added some echoes to see what was occurring. Still, messages appear out of order and some do not appear at all on the droid. I tried copying the actual message files out of various cur dirs and still some were very out of date. The second script seemed to be adjusting the dates of the files properly, but I am not sure what android gmail actually uses to sort. #!/bin/bash for i in `ls /home/brian/Maildir/cur/` do # Find the date field and then remove up to the first space (Date: ) DATE=$(grep '^Date:' $i | head -1 | cut -d' ' -f1 --complement) # Create a timestamp from the date above STAMP=$(date --date="$DATE" +%Y%m%d%H%M) # touch the file with the correct timestamp touch -t $STAMP $i echo "$i stamped" echo "$DATE" echo "$STAMP" done ------------ #!/bin/bash # Fix emails with bad timestamps in a maildir # This script reads the date from the email header and set its UNIX timestamp and renames it with the proper date # e.g. this: # dec. 05 2017 1512499812.M908995P21566.ip-111-11-11-11,S=16331,W=16746:2,S # becomes that (the email Date header is "Date: Tue, 22 Oct 2013 10:07:21 +0100"): # oct. 22 2013 1382432841.M908995P21566.ip-111-11-11-11,S=16331,W=16746:2,S cd "/home/brian/Maildir/cur"; for i in `ls 1482809425.M277770P17438*` do echo "$i" # We extract the date from the email headers DATE=$(grep '^Date:' $i | head -1 | cut -d' ' -f1 --complement) # We compute a touch-compatible timestamp as well as the real timestamp TOUCHSTAMP=$(date --date="$DATE" +%Y%m%d%H%M) TIMESTAMP=$(date --date="$DATE" +%s) # We set the file timestamp touch -t $TOUCHSTAMP $i # We rename the file with preprending timestamp newfilename="$TIMESTAMP.${i#*.}" mv "$i" "$newfilename" echo "$newfilename" echo "******" done

1 0

.IMAP locations
by Elise 03 Apr '21

03 Apr '21

I have this account, /usr/home/me To be able to admin websites, I created a folder /usr/home/me/www , containing my siteroot /usr/home/me/www/mysite.com My dovecot.config: mail_location = mbox:/home/%u:INBOX=/var/mail/%u the actual mailfolder is /usr/home/me/mail , which I defined in my mailclient as 'mail/' The issue now is that Dovecot is indexing my whole /usr/home/me/ folder, including the www folder, in which it also idexes every folder that is in /usr/home/me/www/mysite.com . It puts in these folders an .imap folder that is containing the exact content of the folder it is put in. So my site takes double space by this Dovecot indexing. To solve this issue, I defined my mail_location line as mail_location = mbox:/home/%u/mail:INBOX=/var/mail/%u and removed the 'mail/' directive from my mail client. For some reason this does not prevent Dovecot to index the subfolders of /usr/home/me/www/ - Do I have to remove all Dovecot related indexing files by hand to solve this and restart Dovecot service afterwards? - Can you tell me how I can define the Dovecot index files location so that there will be no .imap folder created anymore in my /usr/home/me/www/ subfolder(s)? Thanks for you help! Elise #CSSis {beautiful};

2 2

Seeking Advice for data recovery
by Riccardo Bicelli 03 Apr '21

03 Apr '21

Hello, we had a drive failure and needed to restore our dovecot server to operational status in no time. So we restored an "old" snapshot backup and worked on the failed drive in order to recover the mails. Data backup didn't worked :-( Now the storage is updated with mails from beginning of time to snapshot, and from recovery day to now, and a copy of the storage of mails from beginning of time to failure. Is there a way to "inject" the mails from "snapshot to failure"? Which is the best way? We're using mdbox. Thanks, Riccardo

1 0

Emails Ending up in Junk
by Asai 03 Apr '21

03 Apr '21

Greetings, I'm trying to debug an issue with a user who is finding emails (user uses Thunderbird as client) ending up in Junk folder, and constantly marks email as Not Junk, but important email ends up in Junk folder. I have sieve set up, but am unable to determine if this is the result of a sieve problem (sieve will automatically move certain emails into Junk if certain headers are present, but these headers are not present on these emails.) I'm looking in Dovecot debug logs to try to figure this out, but all I can find is sometimes this, and I don't know if this is relevant. Can anyone point us in the right direction for solving this issue? Apr 01 11:51:05 imap(user(a)domain.tld)<102535><+kTsYd6+f83AqEbH>: Debug: Mailbox Junk: Mailbox opened because: UID move Apr 01 11:57:08 imap(user(a)domain.tld)<102735><P3dSa96+kM3AqEbH>: Debug: Mailbox Junk: UID 565: Opened mail because: prefetch Apr 01 11:57:08 imap(user(a)domain.tld)<102735><P3dSa96+kM3AqEbH>: Debug: Mailbox Junk: UID 565: Opened mail because: access Apr 01 11:57:08 imap(user(a)domain.tld)<102735><P3dSa96+kM3AqEbH>: Debug: Mailbox Junk: UID 565: Opened mail because: full mail Apr 01 12:00:20 imap(user(a)domain.tld)<71333><OX7P1+2+BfcKCgFy>: Debug: Mailbox Junk: Mailbox opened because: STATUS Apr 01 18:52:10 imap(user(a)domain.tld)<114066><WLt3mPO+z8QKCgFy>: Debug: Mailbox Junk: Mailbox opened because: SELECT

3 3

Virtual folders and mailbox_list_get_root_forced
by Joan Moreau 02 Apr '21

02 Apr '21

Hi The function mailbox_list_get_root_forced returns sometimes the first or the second value of the INDEX param for the same mailbox. How to make sure this returns only the correct one of the corresponding mailbox ? mail_location = maildir:/var/vmail/%d/%n:LAYOUT=fs:INDEX=/var/mailindex namespace { location = virtual:/nix/store/toto-virtual:INDEX=/var/vmail/%d/%n/virtual prefix = virtual/ separator = / subscriptions = no } Thank you

2 5

Re: Re: nginx configuration to pass x-originating-ip
by Henry 01 Apr '21

01 Apr '21

Hello, Does anyone has a solution about it? Thanks

1 0

Replicator: getting full resync requests to sync
by Norman King 31 Mar '21

31 Mar '21

Hello. I'm getting the following output. root@mail:~# doveadm replicator status Queued 'sync' requests 0 Queued 'high' requests 0 Queued 'low' requests 0 Queued 'failed' requests 0 Queued 'full resync' requests 61 Waiting 'failed' requests 4 How can i get the full resync requests to actually sync? Is there a configurable resync delay time that i can use to force a resync of these mailboxes? Also, is there a way using either doveadm replicator or doveadm sync that i can see all the full resync users? Thanks. -- regards Norman King Compass Foundation sysadmin/tech support Phone, 856-974-5335 ext 221 support(a)compassfoundation.io <mailto:support@compassfoundation.io> Website <https://compassfoundation.io>

1 0

RE: Dovecot 2.3.14 - Invalid mailbox name: Name must not have '/'
by Markus Valentin 31 Mar '21

31 Mar '21

> On 03/30/2021 8:25 PM Jürgen Edner <juergen(a)eisfair.org> wrote: > Hi @all, > can anyone please shed some light on the changes of v2.3.14 and what need to be done to get the shared folders working again as in v2.3.13. > I cannot see any invalid characters in the folder names. I would also appreciate any advise on how I can debug the program any further. Hi, can you provide us with the output of `doveconf -n` please? Markus

2 1

Temporary disable push notifications while restoring a mailbox
by Ralf Becker 31 Mar '21

31 Mar '21

We use "doveamd import" to restore mailboxes from a snapshot. Since we use push with Dovecot 2.3.13: mail_plugins = $mail_plugins mail_lua notify push_notification push_notification_lua plugin { push_notification_driver = lua:file=/etc/dovecot/dovecot-push.lua push_lua_url = http://172.17.0.1/ the import creates a flood of push-notifications. Therefore the questions: is there a possibility to disable push for "doveadm import" on the command line (not in general)? Kind regards Ralf -- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0

2 1

Re:dovecot Digest, Vol 215, Issue 77
by 刘莹莹 31 Mar '21

31 Mar '21

------------------ Original ------------------ From: "dovecot" <dovecot-request(a)dovecot.org>; Date: Tue, Mar 30, 2021 11:55 PM To: "dovecot"<dovecot(a)dovecot.org>; Subject: dovecot Digest, Vol 215, Issue 77 Send dovecot mailing list submissions to dovecot(a)dovecot.org To subscribe or unsubscribe via the World Wide Web, visit https://dovecot.org/mailman/listinfo/dovecot or, via email, send a message with subject or body 'help' to dovecot-request(a)dovecot.org You can reach the person managing the list at dovecot-owner(a)dovecot.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dovecot digest..." Today's Topics:    1. special characters in FTS Solr fail (piuma(a)piumalab.org)    2. json_parse_number broken by compiler optimization       (Christian Ehrhardt)    3. Re: json_parse_number broken by compiler optimization (Aki Tuomi) ---------------------------------------------------------------------- Message: 1 Date: Tue, 30 Mar 2021 16:20:56 +0200 From: "piuma(a)piumalab.org" <piuma(a)piumalab.org> To: dovecot(a)dovecot.org Subject: special characters in FTS Solr fail Message-ID: <3c779646-e2fc-9f51-063c-a8816450dbfd(a)piumalab.org> Content-Type: text/plain; charset="utf-8" Hi, I want to report a bug about searching. My dovecot version is 2.3.10.1 (a3d0e1171) and use Solr 7.7.2 for full text search. The issue appear when try to search using solr special characters. For example if I have emails with the subject that contain the only character "(" open parenthesis, then try to search it I receive zero results. In the Solr log seems the "(" is correctly excaped as "\(": 2021-03-30 15:14:20.304 INFO  (qtp333683827-20) [   x:dovecot] o.a.s.c.S.Request [dovecot]  webapp=/solr path=/select params={q={!lucene+q.op%3DAND}subject:\(&fl=uid,score&sort=uid+asc&fq=%2Bbox:6fff5821c5a2365df4060000d0d97f83+%2Buser:titolare01@kendama.it&rows=631&wt=xml} hits=0 status=0 QTime=2 I provide dovecot-sysreport as attachment. Best regards    Danilo -------------- next part -------------- A non-text attachment was scrubbed... Name: dovecot-sysreport-pecbox02.par-tec.it-1617116347.tar.gz Type: application/gzip Size: 7395 bytes Desc: not available URL: <https://dovecot.org/pipermail/dovecot/attachments/20210330/08492366/attachm… ------------------------------ Message: 2 Date: Tue, 30 Mar 2021 17:53:27 +0200 From: Christian Ehrhardt <christian.ehrhardt(a)canonical.com> To: dovecot(a)dovecot.org Subject: json_parse_number broken by compiler optimization Message-ID: <CAATJJ0JB9e4cZrS=hiM0r=yF4-Fz693ZK3qLa41L-rYVfy8QbQ(a)mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hi, the recent Ubuntu (re)builds uncovered an issue with dovecot 1:2.3.13+dfsg1-1 build log: https://launchpadlibrarian.net/529849650/buildlog_ubuntu-hirsute-amd64.dove… A coworker tried 2.3.14 but got the same result. What fails is the json_parser build time test like:   test-json-parser.c:161: Assert(#25) failed: null_strcmp(json_output[pos].value, value) == 0 I was looking into that a bit more and what I found is that it is dependent on the new toolchain of gcc 10.2.0-1. Not all calls to json_parse_* fail, e.g. the first one looks all good and passes I was iterating the tests using a report function defined like (gdb) define repcon >c >p pos >p json_output[pos].type >p type >p json_output[pos].value >p value >call null_strcmp(json_output[pos].value, value) >end The first one to be bad was: Breakpoint 2, test_json_parser_success (full_size=<optimized out>) at test-json-parser.c:161 161 test_assert_idx(null_strcmp(json_output[pos].value, value) == 0, pos); $84 = 25 $85 = JSON_TYPE_NUMBER $86 = JSON_TYPE_NUMBER $87 = 0x555555633b25 "-12.456" $88 = 0x555555693110 "" $89 = 45 Earlier and later parsing was happy, for example Breakpoint 2, test_json_parser_success (full_size=<optimized out>) at test-json-parser.c:161 161 test_assert_idx(null_strcmp(json_output[pos].value, value) == 0, pos); $90 = 27 $91 = JSON_TYPE_NUMBER $92 = JSON_TYPE_NUMBER $93 = 0x555555633b32 "12.456e9" $94 = 0x555555693110 "12.456e9" $95 = 0 (gdb) We have two things we compare here. 1. json_output[] which is a static define and for this value is    67 ????{ JSON_TYPE_NUMBER, "-12.456" }, 2. the return value that json_parse_next returns.    25 ????"  \"sub2\":-12.456,\n"   148 ????????????????ret = json_parse_next(parser, &type, &value); I tried a non negative number and got success which is suspicious Breakpoint 5, test_json_parser_success (full_size=<optimized out>) at test-json-parser.c:164 164 test_assert_idx(null_strcmp(json_output[pos].value, value) == 0, pos); $122 = 25 $123 = JSON_TYPE_NUMBER $124 = JSON_TYPE_NUMBER $125 = 0x555555633b2c "12.456" $126 = 0x555555693110 "12.456" $127 = 0 (gdb) Also the return value otherwise LGTM, it is recognized as a number: 540 } else if ((ret = json_parse_number(parser, value_r)) >= 0) { (gdb) n 541 *type_r = JSON_TYPE_NUMBER; So parsing worked one might think, but the value was not set. (gdb) p *value_r $833 = 0x555555693110 "" It turns out json_parse_number is too optimized. Too optimized for debugging further into json_parse_number. But also optimization is causing the issue. With -O0 or -O1 it works fine, even putting the lower optimization level just around json_parse_number it is enough to avoid the issue. Not a fix but "avoidance" for now: --- a/src/lib/json-parser.c +++ b/src/lib/json-parser.c @@ -386,6 +386,8 @@ static int json_parse_int(struct json_pa   return 1;  } +#pragma GCC push_options +#pragma GCC optimize ("-O0")  static int json_parse_number(struct json_parser *parser, const char **value_r)  {   int ret; @@ -415,6 +417,7 @@ static int json_parse_number(struct json   *value_r = str_c(parser->value);   return 1;  } +#pragma GCC pop_options  static int json_parse_atom(struct json_parser *parser, const char *atom)  { I was trying to see what happened and tracked each str_append_c that happened inside json_parse_number. A breakpoint on str_append_c and backtraces showed that we clearly do the "right" parsing. From the backtraces I've seen it does (just from positions): For example (gdb) bt #0  str_append_c (chr=<optimized out>, str=0x5555556930d0) at str.h:44 #1  json_parse_digits (parser=<optimized out>) at json-parser.c:366 => that is a digit It does "- digit digit dot digit digit digit" This perfectly matches the input value, but still the result stays empty: (gdb) p (char*)(str->data) $738 = 0x555555693110 "" In comparison - when parsing the latter 12.456e9 which works I see two odd things: 1. the value isn't cleared despite     str_truncate(parser->value, 0);    at the beginning of json_parse_number 2. the value (this time) is read exactly as I assumed Breakpoint 17, json_parse_number (value_r=0x7fffffffe1a0, parser=0x555555692ee0) at json-parser.c:394 394 str_truncate(parser->value, 0); Breakpoint 18, str_append_c (chr=<optimized out>, str=0x5555556930d0) at str.h:44 44 buffer_append_c(str, chr); (gdb) p (char*)(str->data) $741 = 0x555555693110 "sub3" ^^ not cleared, still has "sub3" even later on Breakpoint 18, str_append_c (chr=<optimized out>, str=0x5555556930d0) at str.h:44 44 buffer_append_c(str, chr); (gdb) p (char*)(str->data) $742 = 0x555555693110 "1ub3" ^^ reading left to right one char at a time "over the old value", which didn't update the data. So it seems in json_parse_number the ordering of a) str_truncate(parser->value, 0); b) the parsing itself is messed up by optimization. We already know from the above that reducing just this function to -O1 or less avoids the issue. But what is it really - I don't know? Maybe you have a better idea what is going on, the issue should be reproducible when building dovecot with the toolchain present on the latest Ubuntu being 21.04 (Hirsute) right now. -- Christian Ehrhardt Staff Engineer, Ubuntu Server Canonical Ltd ------------------------------ Message: 3 Date: Tue, 30 Mar 2021 18:55:44 +0300 (EEST) From: Aki Tuomi <aki.tuomi(a)open-xchange.com> To: Christian Ehrhardt <christian.ehrhardt(a)canonical.com>, dovecot(a)dovecot.org Subject: Re: json_parse_number broken by compiler optimization Message-ID: <1219230463.3728.1617119744636(a)appsuite-dev-gw1.open-xchange.com> Content-Type: text/plain; charset=UTF-8 > On 30/03/2021 18:53 Christian Ehrhardt <christian.ehrhardt(a)canonical.com> wrote: > >  > Hi, > the recent Ubuntu (re)builds uncovered an issue with dovecot 1:2.3.13+dfsg1-1 > build log: https://launchpadlibrarian.net/529849650/buildlog_ubuntu-hirsute-amd64.dove… > A coworker tried 2.3.14 but got the same result. > > What fails is the json_parser build time test like: >   test-json-parser.c:161: Assert(#25) failed: > null_strcmp(json_output[pos].value, value) == 0 > > I was looking into that a bit more and what I found is that it is > dependent on the new toolchain > of gcc 10.2.0-1. > > Not all calls to json_parse_* fail, e.g. the first one looks all good and passes > I was iterating the tests using a report function defined like > > (gdb) define repcon > >c > >p pos > >p json_output[pos].type > >p type > >p json_output[pos].value > >p value > >call null_strcmp(json_output[pos].value, value) > >end > > The first one to be bad was: > Breakpoint 2, test_json_parser_success (full_size=<optimized out>) at > test-json-parser.c:161 > 161 test_assert_idx(null_strcmp(json_output[pos].value, value) == 0, pos); > $84 = 25 > $85 = JSON_TYPE_NUMBER > $86 = JSON_TYPE_NUMBER > $87 = 0x555555633b25 "-12.456" > $88 = 0x555555693110 "" > $89 = 45 > > Earlier and later parsing was happy, for example > > Breakpoint 2, test_json_parser_success (full_size=<optimized out>) at > test-json-parser.c:161 > 161 test_assert_idx(null_strcmp(json_output[pos].value, value) == 0, pos); > $90 = 27 > $91 = JSON_TYPE_NUMBER > $92 = JSON_TYPE_NUMBER > $93 = 0x555555633b32 "12.456e9" > $94 = 0x555555693110 "12.456e9" > $95 = 0 > (gdb) > > > We have two things we compare here. > 1. json_output[] which is a static define and for this value is >    67 ????{ JSON_TYPE_NUMBER, "-12.456" }, > 2. the return value that json_parse_next returns. >    25 ????"  \"sub2\":-12.456,\n" >   148 ????????????????ret = json_parse_next(parser, &type, &value); > > I tried a non negative number and got success which is suspicious > > Breakpoint 5, test_json_parser_success (full_size=<optimized out>) at > test-json-parser.c:164 > 164 test_assert_idx(null_strcmp(json_output[pos].value, value) == 0, pos); > $122 = 25 > $123 = JSON_TYPE_NUMBER > $124 = JSON_TYPE_NUMBER > $125 = 0x555555633b2c "12.456" > $126 = 0x555555693110 "12.456" > $127 = 0 > (gdb) > > > Also the return value otherwise LGTM, it is recognized as a number: > 540 } else if ((ret = json_parse_number(parser, value_r)) >= 0) { > (gdb) n > 541 *type_r = JSON_TYPE_NUMBER; > > So parsing worked one might think, but the value was not set. > > (gdb) p *value_r > $833 = 0x555555693110 "" > > It turns out json_parse_number is too optimized. > Too optimized for debugging further into json_parse_number. > But also optimization is causing the issue. > With -O0 or -O1 it works fine, even putting the lower optimization > level just around json_parse_number it is enough to avoid the issue. > > > Not a fix but "avoidance" for now: > > --- a/src/lib/json-parser.c > +++ b/src/lib/json-parser.c > @@ -386,6 +386,8 @@ static int json_parse_int(struct json_pa >   return 1; >  } > > +#pragma GCC push_options > +#pragma GCC optimize ("-O0") >  static int json_parse_number(struct json_parser *parser, const char **value_r) >  { >   int ret; > @@ -415,6 +417,7 @@ static int json_parse_number(struct json >   *value_r = str_c(parser->value); >   return 1; >  } > +#pragma GCC pop_options > >  static int json_parse_atom(struct json_parser *parser, const char *atom) >  { > > > I was trying to see what happened and tracked each str_append_c > that happened inside json_parse_number. > A breakpoint on str_append_c and backtraces showed that we clearly do the > "right" parsing. From the backtraces I've seen it does (just from positions): > > For example > (gdb) bt > #0  str_append_c (chr=<optimized out>, str=0x5555556930d0) at str.h:44 > #1  json_parse_digits (parser=<optimized out>) at json-parser.c:366 > => that is a digit > > It does "- digit digit dot digit digit digit" > > This perfectly matches the input value, but still the result stays empty: > (gdb) p (char*)(str->data) > $738 = 0x555555693110 "" > > In comparison - when parsing the latter 12.456e9 which works I see two > odd things: > 1. the value isn't cleared despite >     str_truncate(parser->value, 0); >    at the beginning of json_parse_number > 2. the value (this time) is read exactly as I assumed > > Breakpoint 17, json_parse_number (value_r=0x7fffffffe1a0, > parser=0x555555692ee0) at json-parser.c:394 > 394 str_truncate(parser->value, 0); > Breakpoint 18, str_append_c (chr=<optimized out>, str=0x5555556930d0) > at str.h:44 > 44 buffer_append_c(str, chr); > (gdb) p (char*)(str->data) > $741 = 0x555555693110 "sub3" > > ^^ not cleared, still has "sub3" even later on > > Breakpoint 18, str_append_c (chr=<optimized out>, str=0x5555556930d0) > at str.h:44 > 44 buffer_append_c(str, chr); > (gdb) p (char*)(str->data) > $742 = 0x555555693110 "1ub3" > > ^^ reading left to right one char at a time "over the old value", > which didn't update the data. > > So it seems in json_parse_number the ordering of > a) str_truncate(parser->value, 0); > b) the parsing itself > is messed up by optimization. > > We already know from the above that reducing just this function to -O1 or less > avoids the issue. But what is it really - I don't know? > > Maybe you have a better idea what is going on, the issue should be > reproducible when building > dovecot with the toolchain present on the latest Ubuntu being 21.04 > (Hirsute) right now. > > -- > Christian Ehrhardt > Staff Engineer, Ubuntu Server > Canonical Ltd Thanks! We'll look into this. Aki ------------------------------ Subject: Digest Footer _______________________________________________ dovecot mailing list dovecot(a)dovecot.org https://dovecot.org/mailman/listinfo/dovecot ------------------------------ End of dovecot Digest, Vol 215, Issue 77 ****************************************

1 0

RE: Dovecot 2.3.14 - Invalid mailbox name: Name must not have '/'
by Jürgen Edner 30 Mar '21

30 Mar '21

Hi @all, can anyone please shed some light on the changes of v2.3.14 and what need to be done to get the shared folders working again as in v2.3.13. I cannot see any invalid characters in the folder names. I would also appreciate any advise on how I can debug the program any further. Thanks Juergen -- Email: juergen(a)eisfair.org

1 0

special characters in FTS Solr fail
by piuma＠piumalab.org 30 Mar '21

30 Mar '21

Hi, I want to report a bug about searching. My dovecot version is 2.3.10.1 (a3d0e1171) and use Solr 7.7.2 for full text search. The issue appear when try to search using solr special characters. For example if I have emails with the subject that contain the only character "(" open parenthesis, then try to search it I receive zero results. In the Solr log seems the "(" is correctly excaped as "\(": 2021-03-30 15:14:20.304 INFO (qtp333683827-20) [ x:dovecot] o.a.s.c.S.Request [dovecot] webapp=/solr path=/select params={q={!lucene+q.op%3DAND}subject:\(&fl=uid,score&sort=uid+asc&fq=%2Bbox:6fff5821c5a2365df4060000d0d97f83+%2Buser:titolare01@kendama.it&rows=631&wt=xml} hits=0 status=0 QTime=2 I provide dovecot-sysreport as attachment. Best regards Danilo

1 0

Replication - I/O has stalled
by Stefan Möding 29 Mar '21

29 Mar '21

Hi! I'm running Dovecot 2.3.14 from the Dovecot repo on Debian-9. I've configured replication and often notice the following log messages: Mar 29 09:23:13 atlantia dovecot: doveadm: Error: Couldn't lock /var/spool/vmail/stm/.dovecot-sync.lock: fcntl(/var/spool/vmail/stm/.dovecot-sync.lock, write-lock, F_SETLKW) locking failed: Timed out after 30 seconds (WRITE lock held by pid 30810) Mar 29 09:27:43 atlantia dovecot: dsync-local(stm)<d79ZNRZ/YWBaeAAAr9pkTg>: Error: dsync(pacifica.moeding.net): I/O has stalled, no activity for 600 seconds (last sent=mailbox, last recv=mailbox_state) Mar 29 09:27:43 atlantia dovecot: dsync-local(stm)<d79ZNRZ/YWBaeAAAr9pkTg>: Error: Timeout during state=sync_mails (send=mailbox recv=mailbox) Process 30810 is doveadm-server when this happended: PID TTY STAT TIME COMMAND 1080 ? Ss 0:07 /usr/sbin/dovecot -F 1091 ? S 0:01 \_ dovecot/replicator 1094 ? S 0:01 \_ dovecot/anvil [2 connections] 1095 ? S 0:02 \_ dovecot/log 1096 ? S 0:06 \_ dovecot/stats [6 connections] 1098 ? S 0:14 \_ dovecot/config 1101 ? S 0:07 \_ dovecot/auth [0 wait, 0 passdb, 0 userdb] 4728 ? S 0:00 \_ dovecot/aggregator 30668 ? S 0:00 \_ dovecot/imap-login 30670 ? S 0:00 \_ dovecot/imap 30810 ? S 0:00 \_ dovecot/doveadm-server [stm System send:mailbox recv:mailbox] Sometimes these error occur once every hour. I have replication_full_sync_interval = 1 hours, so I have the strong feeling that this is the cause. Maybe there is a race condition when full syncs are started concurrently on both sides? Is anybody else observing this? -- Stefan

1 0

Public NameSpace using sdbox with INDEXPVT for per-user-seen flags does not take into account the dovecot-shared file flag
by Panayiotis Fafakos 29 Mar '21

29 Mar '21

Dear Timo, we have successfully used *dovecot-shared* file flag in *Maildir **Public *NameSpaces with private index files, to have per-user-seen flags for some but not all *mailboxes *under public folders. This was actually done on older dovecot versions (i.e *dovecot v2.2.33.2*) , using a *location* setting in *dovecot.conf* like: location = maildir:/var/vmail/PublicFolders:LAYOUT=fs:DIRNAME=privDirMailFolder:INDEX=~/Maildir/public We try to use similar *location* setting using *sdbox* storage in *dovecot v2.3.4.1*, like below: location = sdbox:/var/vmail/PublicFolders:LAYOUT=fs:DIRNAME=dbox-MailFolder:INDEXPVT=~/Maildir/public but the *dovecot-shared *file flag seems to be ignored. As a result all mailboxes under public folders use the per-user-seen flags setting as set in the location setting, regardless of the existence of the dovecot-shared file flag or not. Is there any setting to use so that only some mailboxes under public folders use per-user-seen flags? Thank you in advance for your support, Panos Fafakos.

2 2

Dovecot 2.3.14 - Invalid mailbox name: Name must not have '/' character
by Juergen Edner 27 Mar '21

27 Mar '21

Hi, after upgrading from Dovecot v2.3.13 to v2.3.14 I realized that shared sub-folders, e.g. "Lieferanten/Rechnungen", cannot be accessed anymore, although the underlying configuration hasn't been changed at all. If I try to access such a folder using e.g. Thunderbird the error "Invalid mailbox name: Name must not have '/' character." is shown instead of opening the folder. Now I wonder if this is a bug or feature or what need to be done to get the previous function back. In the change notes of the latest Dovecot version I found the following point, which might be the root cause of the problem: * If BROKENCHAR or listescape plugin is used, the escaped folder names may be slightly different from before in some situations. This is unlikely to cause issues, although caching clients may redownload the folders. These are my shared folder configuration parameters: namespace { location = maildir:/home/imapshared:INDEXPVT=~/.imapmail/shared prefix = "#Shared/" separator = / subscriptions = no type = shared } protocol imap { mail_max_userip_connections = 15 mail_plugins = " listescape" } I also checked how the shared folders are returned with both Dovecot version and cannot find any difference in the naming, except that the v2.3.13 correctly labels one folder as "\HasChildren", which v2.3.14 doesn't?! v2.3.13: a list "#Shared/" "*" * LIST (\HasChildren) "/" #Shared/Lieferanten * LIST (\HasNoChildren) "/" #Shared/Lieferanten/Rechnungen v2.3.14: a list "#Shared/" "*" * LIST (\HasNoChildren) "/" #Shared/Lieferanten * LIST (\HasNoChildren) "/" #Shared/Lieferanten/Rechnungen Any help/hint is highly appreciated. Thanks Juergen --

1 0

Dovecot 2.3.14 - Invalid mailbox name: Name must not have '/' character
by Jürgen Edner 27 Mar '21

27 Mar '21

Hi, after upgrading from Dovecot v2.3.13 to v2.3.14 I realized that shared sub-folders, e.g. "Lieferanten/Rechnungen", cannot be accessed anymore, although the underlying configuration hasn't been changed at all. If I try to access such a folder using e.g. Thunderbird the error "Invalid mailbox name: Name must not have '/' character." is shown instead of opening the folder. Now I wonder if this is a bug or feature or what need to be done to get the previous function back. In the change notes of the latest Dovecot version I found the following point, which might be the root cause of the problem: * If BROKENCHAR or listescape plugin is used, the escaped folder names may be slightly different from before in some situations. This is unlikely to cause issues, although caching clients may redownload the folders. These are my shared folder configuration parameters: namespace { location = maildir:/home/imapshared:INDEXPVT=~/.imapmail/shared prefix = "#Shared/" separator = / subscriptions = no type = shared } protocol imap { mail_max_userip_connections = 15 mail_plugins = " listescape" } I also checked how the shared folders are returned with both Dovecot version and cannot find any difference in the naming, except that the v2.3.13 correctly labels one folder as "\HasChildren", which v2.3.14 doesn't?! v2.3.13: a list "#Shared/" "*" * LIST (\HasChildren) "/" #Shared/Lieferanten * LIST (\HasNoChildren) "/" #Shared/Lieferanten/Rechnungen v2.3.14: a list "#Shared/" "*" * LIST (\HasNoChildren) "/" #Shared/Lieferanten * LIST (\HasNoChildren) "/" #Shared/Lieferanten/Rechnungen Any help/hint is highly appreciated. Thanks Juergen --

1 0

dsync error: Can't sync mailbox tmp: Mailbox isn't selectable
by Hagen Bauer 27 Mar '21

27 Mar '21

Hi, I am trying to use dsync to migrate from mbox to Maildir with dovecot --version 2.2.27 () The configuration seems to be working and some of the mailbox can be mirrored via dsync -u username mirror mbox:/home/username/mail:INBOX=/var/mail/username I have trouble with one user where I get the error. dsync(username2): Error: Can't sync mailbox tmp: Mailbox isn't selectable Any ideas where to look for hints? Regards Hagen Bauer

2 2

ssl_verify_client_cert=yes does not require a client certificate
by Hristo Venev 27 Mar '21

27 Mar '21

Hello, I am trying to set up LMTP over TLS. I have set ssl_verify_client_cert: protocol lmtp { ssl_ca = </etc/cert/mail/ca.pem ssl_cert = </etc/cert/mail/host.pem ssl_key = </etc/cert/mail/host.key ssl_verify_client_cert = yes } However, clients can still connect without presenting a valid certificate. In openssl_iostream_set() the flags given to SSL_set_verify() are SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE. For a certificate to be required, the SSL_VERIFY_FAIL_IF_NO_PEER_CERT flag also needs to be set: diff --git a/src/lib-ssl-iostream/iostream-openssl.c b/src/lib-ssl-iostream/iostream-openssl.c index 5d11526f1..d8df96398 100644 --- a/src/lib-ssl-iostream/iostream-openssl.c +++ b/src/lib-ssl-iostream/iostream-openssl.c @@ -235,7 +235,7 @@ openssl_iostream_set(struct ssl_iostream *ssl_io, if (ssl_io->ctx->client_ctx) verify_flags = SSL_VERIFY_NONE; else - verify_flags = SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE; + verify_flags = SSL_VERIFY_PEER | SSL_VERIFY_CLIENT_ONCE | SSL_VERIFY_FAIL_IF_NO_PEER_CERT; SSL_set_verify(ssl_io->ssl, verify_flags, openssl_iostream_verify_client_cert); }

2 2

Strange error on multiple recipent email - permission denied
by Salatiel Filho 27 Mar '21

27 Mar '21

Hi, I am doing some tests with dovecot to replace cyrusimapd, but after the most simple configuration I am getting some strange errors on log. This is the output of dovecot -n: #davecot -n disable_plaintext_auth = no ( just for testing ) first_valid_uid = 1000 mail_location = mbox:/var/spool/mail/%n mail_privileged_group = mail mbox_write_locks = fcntl 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 { driver = pam } protocols = imap lmtp ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_cipher_list = PROFILE=SYSTEM ssl_key = # hidden, use -P to show it userdb { driver = passwd } I have also chmod a+rwxt on /var/spool/mail and set. Now here is the strange behavior. I have 2 users created, user1 and user2. At first , there are no files on /var/spool/mail as expected. Now I send one email to user1@mydomain and I can receive just fine and there are no errors on logs. Mar 27 00:32:20 mx2 dovecot[1473]: lmtp(1504): Connect from local Mar 27 00:32:20 mx2 sendmail[1503]: STARTTLS=client, relay=localhost, version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256 Mar 27 00:32:20 mx2 dovecot[1473]: lmtp(user1)<1504><hzMPOBR9XmDgBQAAUY4zkw>: lmtp-server: conn unix:pid=1503,uid=0 [1]: rcpt user1: msgid=<CAGmni9qUfh_EntW-mMvdTK=bCc3QVQ+74f8X3BzBa5Z0dYi+-g(a)mail.gmail.com>: saved mail to INBOX Mar 27 00:32:20 mx2 sendmail[1503]: 12R0WKV0001502: to=<user1(a)mydomain.here>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=32320, relay=localhost, dsn=2.0.0, stat=Sent Mar 27 00:32:20 mx2 sendmail[1503]: 12R0WKV0001502: done; delay=00:00:00, ntries=1 Mar 27 00:32:20 mx2 dovecot[1473]: lmtp(1504): Disconnect from local: Client has quit the connection (state=READY) Now I send one email to user2@mydomain and I can receive just fine and there are no errors on logs. Mar 27 00:33:45 mx2 dovecot[1473]: lmtp(1510): Connect from local Mar 27 00:33:46 mx2 sendmail[1509]: STARTTLS=client, relay=localhost, version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256 Mar 27 00:33:46 mx2 dovecot[1473]: lmtp(user2)<1510><IUlGAWp9XmDmBQAAUY4zkw>: lmtp-server: conn unix:pid=1509,uid=0 [1]: rcpt user2: msgid=<CAGmni9qDHgDw=M6XPMk_eWb+02OJmCMarVe8sc_B4rNYUGMfGw(a)mail.gmail.com>: saved mail to INBOX Mar 27 00:33:46 mx2 sendmail[1509]: 12R0XjKj001508: to=<user2(a)mydomain.here>, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=32318, relay=localhost, dsn=2.0.0, stat=Sent Mar 27 00:33:46 mx2 sendmail[1509]: 12R0XjKj001508: done; delay=00:00:01, ntries=1 Mar 27 00:33:46 mx2 dovecot[1473]: lmtp(1510): Disconnect from local: Client has quit the connection (state=READY) The problem starts if I send one email to user1 AND user2 ( user2 can be in TO or CC ) Mar 27 00:35:04 mx2 dovecot[1473]: lmtp(user2)<1518><AxH4Nbh9XmDuBQAAUY4zkw>: lmtp-server: conn unix:pid=1517,uid=0 [1]: rcpt user2: msgid=<CAGmni9oqid6pAEWPynAq9to-u0YdxE2o65wS34aeevnEWLj=AA(a)mail.gmail.com>: saved mail to INBOX Mar 27 00:35:04 mx2 dovecot[1473]: lmtp(user1)<1518><AxH4Nbh9XmDuBQAAUY4zkw:2>: Error: lmtp-server: conn unix:pid=1517,uid=0 [1]: rcpt user2: stat(/var/spool/mail/user2/.imap/INBOX/dovecot.index.log) failed: Permission denied (euid=1003(user1) egid=1003(user1) missing +x perm: /var/spool/mail/user2, dir owned by 1004:1004 mode=0700) Mar 27 00:35:04 mx2 dovecot[1473]: lmtp(user1)<1518><AxH4Nbh9XmDuBQAAUY4zkw:2>: Error: lmtp-server: conn unix:pid=1517,uid=0 [1]: rcpt user2: open(/var/spool/mail/user2/.imap/INBOX/dovecot.index) failed: Permission denied (euid=1003(user1) egid=1003(user1) missing +x perm: /var/spool/mail/user2, dir owned by 1004:1004 mode=0700) Mar 27 00:35:04 mx2 dovecot[1473]: lmtp(user1)<1518><AxH4Nbh9XmDuBQAAUY4zkw:2>: lmtp-server: conn unix:pid=1517,uid=0 [1]: rcpt user1: msgid=<CAGmni9oqid6pAEWPynAq9to-u0YdxE2o65wS34aeevnEWLj=AA(a)mail.gmail.com>: saved mail to INBOX Mar 27 00:35:04 mx2 sendmail[1517]: 12R0Z4h0001516: to=<user2(a)mydomain.here>,<user1(a)mydomain.here>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=62302, relay=localhost, dsn=2.0.0, stat=Sent Mar 27 00:35:04 mx2 sendmail[1517]: 12R0Z4h0001516: done; delay=00:00:00, ntries=1 Mar 27 00:35:04 mx2 dovecot[1473]: lmtp(1518): Disconnect from local: Client has quit the connection (state=READY) Although I can receive the email, there's an ERROR log in maillog. It appears user1 wants to open the user2 index file. Any ideas why ? Thank you very much!

1 0

How to dimension hardware when using replication?
by Michael Westerburg 25 Mar '21

25 Mar '21

Hello Postmaster, for a decade we have been using Dovecot successfully as IMAP server at Augsburg University. Now we face the decision to switch from separated SAN storage to mirrored SAN storage by means of the usual combination of dovecot director and dovecot replicator (CentOS 7, Dovecot 2.2.36). Dovecot director runs on four virtual machines (4 cores, 4 GB memory). The replicated storage is handled by two HP servers with 2 Xeon(R) CPU E5-2620 (6 cores) and 32 GM memory. The network relies on 2 x 1 GBit Ethernet bond and two redundant 4 GBit SAN-fabrics. Our concerns, (1) is this equipment suitable? We are talking here about 25.000 mail accounts (LDAP) with 7 TB mail storage (mdbox) and in peak periods 10.000 parallel Dovecot processes and (2) what are adequate settings for director_user_expire, replication_max_conns and replication_full_sync_interval? Loosing mails is unacceptable as well as users stumbling upon mails with the recent flag set which were read and deleted yesterday. Who is using dovecot director and replicator and is willing to share settings and operational experience? Thanks in advance ++ Michael Westerburg -- Dr. Michael Westerburg Universität Augsburg Rechenzentrum 86135 Augsburg Telefon 0821/598-2004 Telefax 0821/598-2028 michael.westerburg(a)rz.uni-augsburg.de https://www.rz.uni-augsburg.de

1 0

Backtrace on UID SORT and UID SEARCH
by Pedro Ribeiro 25 Mar '21

25 Mar '21

Hello, I'm seeing a few backtraces like this ones in our daily log file. It always seem to happen during UID SEARCH or UID SORT I've already increased some process memory limits in the past and I'm currently using: default_vsz_limit = 512 M Is this some bug or I just need to increase this memory limit or some specific of a process? Using Dovecot 2.3.13 on Gentoo Linux amd64 Build options: ioloop=epoll notify=inotify openssl io_block_size=8192 SQL drivers: mysql Passdb: checkpassword passwd passwd-file shadow sql Userdb: checkpassword passwd prefetch passwd-file sql > Error: Raw backtrace: > /usr/lib64/dovecot/libdovecot.so.0(backtrace_append+0x3d) [0x7efd24b8c04d] > /usr/lib64/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7efd24b8c15e] > /usr/lib64/dovecot/libdovecot.so.0(+0xf4fcb) [0x7efd24b97fcb] > /usr/lib64/dovecot/libdovecot.so.0(+0xf5061) [0x7efd24b98061] > /usr/lib64/dovecot/libdovecot.so.0(+0x4e25b) [0x7efd24af125b] > /usr/lib64/dovecot/libdovecot.so.0(+0x4fcf1) [0x7efd24af2cf1] > /usr/lib64/dovecot/libdovecot.so.0(i_stream_read+0x2a) [0x7efd24ba3e3a] > /usr/lib64/dovecot/libdovecot.so.0(i_stream_read_data+0x3d) > [0x7efd24ba477d] > /usr/lib64/dovecot/libdovecot.so.0(message_parse_header_next+0x69) > [0x7efd24b766b9] > /usr/lib64/dovecot/libdovecot.so.0(+0xd613a) [0x7efd24b7913a] > /usr/lib64/dovecot/libdovecot.so.0(+0xd62bf) [0x7efd24b792bf] > /usr/lib64/dovecot/libdovecot.so.0(message_parser_parse_next_block+0x44) > [0x7efd24b78894] > /usr/lib64/dovecot/libdovecot.so.0(message_search_msg+0xa0) > [0x7efd24b7acd0] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0xcec2e) [0x7efd24f2ec2e] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0x517c9) [0x7efd24eb17c9] > /usr/lib64/dovecot/libdovecot-storage.so.0(mail_search_args_foreach+0x45) > [0x7efd24eb27f5] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0xcf96b) [0x7efd24f2f96b] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0xd0d29) [0x7efd24f30d29] > /usr/lib64/dovecot/libdovecot-storage.so.0(index_storage_search_next_nonblock+0x61) > [0x7efd24f313b1] > /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_search_next_nonblock+0x20) > [0x7efd24ebc240] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID SORT](+0x26e97) > [0x564e1e21de97] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID > SORT](imap_search_start+0xdc) [0x564e1e21e70c] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID > SORT](cmd_sort+0x24b) [0x564e1e21058b] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID > SORT](command_exec+0x64) [0x564e1e216d74] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID SORT](+0x1deaf) > [0x564e1e214eaf] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID SORT](+0x1df62) > [0x564e1e214f62] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID SORT](+0x1e133) > [0x564e1e215133] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID > SORT](client_handle_input+0x1ad) [0x564e1e21532d] > dovecot/imap [someuser2@ourdom 2001:1234::fb8 UID > SORT](client_input+0x72) [0x564e1e2157e2] > /usr/lib64/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7efd24bad989] > Error: Raw backtrace: > /usr/lib64/dovecot/libdovecot.so.0(backtrace_append+0x3d) [0x7f3c6b7b104d] > /usr/lib64/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f3c6b7b115e] > /usr/lib64/dovecot/libdovecot.so.0(+0xf4fcb) [0x7f3c6b7bcfcb] > /usr/lib64/dovecot/libdovecot.so.0(+0xf5061) [0x7f3c6b7bd061] > /usr/lib64/dovecot/libdovecot.so.0(+0x4e25b) [0x7f3c6b71625b] > /usr/lib64/dovecot/libdovecot.so.0(+0x4fcf1) [0x7f3c6b717cf1] > /usr/lib64/dovecot/libdovecot.so.0(i_stream_read+0x2a) [0x7f3c6b7c8e3a] > /usr/lib64/dovecot/libdovecot.so.0(i_stream_read_data+0x3d) > [0x7f3c6b7c977d] > /usr/lib64/dovecot/libdovecot.so.0(message_parse_header_next+0x69) > [0x7f3c6b79b6b9] > /usr/lib64/dovecot/libdovecot.so.0(+0xd613a) [0x7f3c6b79e13a] > /usr/lib64/dovecot/libdovecot.so.0(+0xd62bf) [0x7f3c6b79e2bf] > /usr/lib64/dovecot/libdovecot.so.0(message_parser_parse_next_block+0x44) > [0x7f3c6b79d894] > /usr/lib64/dovecot/libdovecot.so.0(message_search_msg+0xa0) > [0x7f3c6b79fcd0] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0xcec2e) [0x7f3c6bb53c2e] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0x517c9) [0x7f3c6bad67c9] > /usr/lib64/dovecot/libdovecot-storage.so.0(mail_search_args_foreach+0x45) > [0x7f3c6bad77f5] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0xcf96b) [0x7f3c6bb5496b] > /usr/lib64/dovecot/libdovecot-storage.so.0(+0xd0d29) [0x7f3c6bb55d29] > /usr/lib64/dovecot/libdovecot-storage.so.0(index_storage_search_next_nonblock+0x10d) > [0x7f3c6bb5645d] > /usr/lib64/dovecot/libdovecot-storage.so.0(mailbox_search_next_nonblock+0x20) > [0x7f3c6bae1240] > dovecot/imap [someuser@ourdom 192.168.166.58 UID SEARCH](+0x26e97) > [0x563bbf06de97] > dovecot/imap [someuser@ourdom 192.168.166.58 UID > SEARCH](command_exec+0x64) [0x563bbf066d74] > dovecot/imap [someuser@ourdom 192.168.166.58 UID SEARCH](+0x265e2) > [0x563bbf06d5e2] > /usr/lib64/dovecot/libdovecot.so.0(io_loop_handle_timeouts+0x123) > [0x7f3c6b7d27b3] > /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xc7) > [0x7f3c6b7d3ed7] > /usr/lib64/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) > [0x7f3c6b7d2a30] > /usr/lib64/dovecot/libdovecot.so.0(io_loop_run+0x40) [0x7f3c6b7d2ba0] > /usr/lib64/dovecot/libdovecot.so.0(master_service_run+0x13) > [0x7f3c6b74a393] > dovecot/imap [someuser@ourdom 192.168.166.58 UID SEARCH](main+0x459) > [0x563bbf0571a9] > /lib64/libc.so.6(__libc_start_main+0xeb) [0x7f3c6b33182b] regards! -- Best regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Pedro Ribeiro Politécnico de Lisboa, Serviços da Presidência Departamento de Sistemas de Informação e Comunicações Phone: +351 210 464 700 (general) / VoIP: 80100 Helpdesk: helpdesk(a)net.ipl.pt / https://www.net.ipl.pt =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2 1

doveadm REST API: Delete home
by Patrick Ben Koetter 24 Mar '21

24 Mar '21

Hi! How can I remove a users mail home directory using the REST API? I'm trying to purge a users mailbox including the users $HOME, but it seems I'm on the wrong way. If I send a mailbox delete I end up with "Error: Can't delete INBOX: INBOX can't be deleted.", which kind of makes sense. Should I be using https://doc.dovecot.org/admin_manual/doveadm_http_api/#doveadm-fs-delete instead? TIA, p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein

1 0