Re: sieve-extdata plugin breaks on pigeonhole 0.5 ish

2020-10-31 Thread Stephan Bosch 




On 19/09/2020 08:05, Sebastiaan Hoogeveen wrote:

Hi Ed,

On 18/09/2020 23:37, Ed W wrote:
Hi, I wonder if someone could give me a little help bringing the 
sieve-extdata plugin up to date to be usable with latest 
Dovecot/pigeonhole


Trying to use both together at present I get an error:

   managesieve: Fatal: Couldn't load required plugin 
/usr/lib/dovecot/sieve/lib90_sieve_extdata_plugin.so: dlopen() 
failed: /usr/lib/dovecot/sieve/lib90_sieve_extdata_plugin.so: 
undefined symbol: sieve_sys_error



This appears to be due to the change in error handling in pigeonhole 
0.5 which appears to have removes the "sieve_sys_error()" and 
"sieve_sys_warning()" functions


I'm unclear how this code should be change (I've commented it out for 
now - eek).
You're not alone, I ran into the same problem a couple of days ago. 
Applying the patch from my pull request at
https://github.com/stephanbosch/sieve-extdata-plugin/pull/1 will 
probably fix this problem.


Pushed fixes and updates.

Regards,

Stephan.

Re: v2.3.11.3 solr plugin search via MUA fails to match accented ascii characters; cmd line exec of `doveadm fts lookup` PANICs (assertion failed) [proposed patch]

2020-10-31 Thread PGNet Dev 

On 10/31/20 9:55 AM, John Fawcett wrote:

I can contribute a patch that solves the segfault. Unfortunately though
fts search may be more broken than this. It does not give me search
results, even though I see it querying solr and getting hits.


Thx -- hopefully it moves this in the right direction.

Also on the 'good news' page, it appears there's been some progress on 
Thunderbird's use of backend/server search,

TBird "search on server" doesn't -- NO comm with backend IMAP/SOLR; 
appears to be local-only search
 https://bugzilla.mozilla.org/show_bug.cgi?id=1673928

"A fix for this is upcoming."

Remains to be seen if the doveadm search issues, and implications on backend 
problems, have any effect on the Thunderbird searches.

Dovecot, sa-learn and sieve - where to save the Bayes DB

2020-10-31 Thread Francis Augusto Medeiros-Logeay 

Hi!

I have dovecot, Spamassassin and postfix running. I started to use 
sa-learn to get better and more precise spam identification and 
filtering.


I have not set the Bayes_path preference on my local.cf file, thus when 
I call sa-learn -u myu...@mydomain.org --spam, the Bayes DB gets updated 
at /root/.spamassassin.


I decided then to create a sieve filter on dovecot, as described on 
Dovecot's wiki page. Basically, Dovecot's sieve plugin execute sa-learn 
with a -u argument, apparently the same way I do when I use it manually.


BUT, the thing is that when Dovecot executes sa-learn, the bayes 
database is created on the virtual user's folder, ie., 
/var/mail/vmail/mydomain.org/user/.spamassassin. When I call it 
manually, the db used is /root/.spamassassin`


I am now confused as I don't know if, when evaluating spam, spamd will 
use the Bayes DB on the user's Maildir, or if it will use the one under 
/root/.spamassassin.


I would really like to have my spam evaluation done per user, not site 
wide, so I wonder:


- How can I configure bayes_path for each user, individually, on a 
virtual users setup?
- Does calling spamd with --virtual-config-dir have anything to do with 
this? I tried it, setting it up with my virtual users path, but it 
didn't seem to make any difference when it comes to what I describe in 
this post. With or without it set up, the results above are the same.


--
Francis Augusto Medeiros-Logeay
Oslo, Norway

Re: v2.3.11.3 solr plugin search via MUA fails to match accented ascii characters; cmd line exec of `doveadm fts lookup` PANICs (assertion failed) [proposed patch]

2020-10-31 Thread John Fawcett 
On 31/10/2020 04:57, PGNet Dev wrote:
> On 10/18/20 10:28 PM, Aki Tuomi wrote:
>>> doveadm(myu...@example.com): Panic: file mail-storage.c: line
>>> 2112 (mailbox_get_open_status): assertion failed: (box->opened)
> ...
>
>> I can reproduce your problem with the `fts lookup` command. Luckily
>> it's equivalent to running `doveadm search`. I'll open a bug about this.
>
> Can you provide any status on the bug/fix?
>
> Thanks.

I can contribute a patch that solves the segfault. Unfortunately though
fts search may be more broken than this. It does not give me search
results, even though I see it querying solr and getting hits.

diff -ur dovecot-2.3.11.3-orig/src/plugins/fts/doveadm-fts.c
dovecot-2.3.11.3-patch/src/plugins/fts/doveadm-fts.c
--- dovecot-2.3.11.3-orig/src/plugins/fts/doveadm-fts.c    2020-08-12
14:20:41.0 +0200
+++ dovecot-2.3.11.3-patch/src/plugins/fts/doveadm-fts.c    2020-10-31
17:52:09.019388695 +0100
@@ -47,6 +47,14 @@
 i_array_init(, 16);
 
 box = mailbox_alloc(info->ns->list, info->vname, 0);
+    mailbox_set_reason(box,"fts search");
+    if (mailbox_open(box) < 0) {
+        i_error("Couldn't open mailbox: %s",
+            mailbox_get_last_internal_error(box, NULL));
+        doveadm_mail_failed_error(ctx, MAIL_ERROR_TEMP);
+        return -1;
+    }
+
 if (fts_backend_lookup(backend, box, ctx->search_args->args,
               FTS_LOOKUP_FLAG_AND_ARGS, ) < 0) {
     i_error("fts lookup failed");

On a more minor issue, with this patch if you search for a non existent
mailbox, it does give a segfault for a different assert, in mail-user.c
(*user)->refcount == 1.

doveadm(j...@voipsupport.it): Error: Couldn't open mailbox: Mailbox
doesn't exist: inboxx
doveadm(j...@voipsupport.it): Panic: file mail-user.c: line 229
(mail_user_deinit): assertion failed: ((*user)->refcount == 1)
doveadm(j...@voipsupport.it): Error: Raw backtrace:
/usr/local/lib/dovecot/libdovecot.so.0(backtrace_append+0x42)
[0x7f35c44c3ee2] ->
/usr/local/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e)
[0x7f35c44c3fee] -> /usr/local/lib/dovecot/libdovecot.so.0(+0xec53e)
[0x7f35c44ce53e] -> /usr/local/lib/dovecot/libdovecot.so.0(+0xec581)
[0x7f35c44ce581] -> /usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0)
[0x7f35c44254ea] ->
/usr/local/lib/dovecot/libdovecot-storage.so.0(+0x56d87)
[0x7f35c47e4d87] -> doveadm(+0x2cb28) [0x55c0eaa57b28] ->
doveadm(+0x2d77c) [0x55c0eaa5877c] ->
doveadm(doveadm_cmd_ver2_to_mail_cmd_wrapper+0x21d) [0x55c0eaa5960d] ->
doveadm(doveadm_cmd_run_ver2+0x472) [0x55c0eaa6a372] ->
doveadm(doveadm_cmd_try_run_ver2+0x37) [0x55c0eaa6a497] ->
doveadm(main+0x1d4) [0x55c0eaa47c54] ->
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7f35c3d34555] ->
doveadm(+0x1d0ef) [0x55c0eaa480ef]
Aborted

John

Re: Indexer error after upgrade to 2.3.11.3 [trial patch]

2020-10-31 Thread John Fawcett 
On 31/10/2020 15:15, Scott Q. wrote:
> But do you know how this bug was introduced ?
>
> I checked the history of that file and don't see anything introduced
> recently that might cause
> this: 
> https://github.com/dovecot/core/commits/master/src/lib-http/http-client-request.c
> 
>
> The only one that might be somewhat related is this one from Apr 27 by
> Stephan Bosch
>
> https://github.com/dovecot/core/commit/799b52accf71e86756dde738d22c1c6a500a7e29#diff-1c02b3481573ffd33c9abccd3f5a6752a5cd81ca83389f4380657f7309c06366
> 
>
I don't know exactly. I'm guess it's not the above commit, since the
problem is happening only when payload_finished is TRUE on arriving at
the start of the http_client_request_send_more function and those lines
set it to FALSE. Though I can't exclude it that it might be an indirect
effect of this.

There are two places where http_client_request_send_more is called but
the problematic call is the one that occurs in http-client-connection.c
within the http_client_connection_continue_request function.

I wasn't able to identify a specific commit that introduced this
problem. The http-client-connection.c file and the whole library has
undergone numerous non trivial commits between 2.3.10 and 2.3.11.3 so
the answer is not easy to identify by code inspectiion. With the various
changes, the code now gets to http_client_request_send_more with
payload_finished true but with payload_input NULL whereas in 2.3.10
payload_input was not NULL. (It's a logical deduction from the fact we
didn't see the assert failures before and that part of the code has not
changed).

John

Re: Odd replication behaviour

2020-10-31 Thread James Pattinson 
Solved. I knew this would happen. The act of writing it all out and including 
the configuration output gave me the solution.

I am using lmtp to deliver mail from postfix to Dovecot. I was missing the 
notify and replication plugins from 20-lmtp.conf

They were only present in 10-mail.conf as

mail_plugins = notify replication

Now, adding to 20-lmtp.conf:

protocol lmtp {
  mail_plugins = sieve notify replication
}

Works fine now. Hope this helps someone else.

Cheers
James

> On 31 Oct 2020, at 14:40, James Pattinson  wrote:
> 
> Hi,
> 
> I have just built a new pair of similar machines both running CentOS 8.2 
> (selinux disabled) and Dovecot 2.3.8 (9df20d2db).
> 
> One machine is a VPS (host A) and one is on my home network (host B). The 
> idea is that they are set up in a master/master config with Dovecot 
> replication.
> 
> I seem to have this 95% working but there is one strange issue I can’t work 
> out.
> 
> Currently B is a perfect replica of A. I have pointed an instance of 
> Thunderbird at it, and I can see all my mails. If I delete any mails or 
> change any flags, I see the same changes almost instantly on the A side.
> 
> PROBLEM: if host A receives a new mail, I don’t see it on B until I do 
> ‘something’ to change metadata, for example deleting any random email, or 
> marking an email as read on EITHER side causes the new email to appear almost 
> instantly on the B side.
> 
> I would have expected emails on B to appear immediately. Am I doing something 
> wrong?
> 
> Extra info -  my mailboxes are in Maildir format with single OS user (vmail). 
> I have about 4000 emails in the Inbox and about 30k in other folders.
> 
> There are only 5 users and I’m using passdb as the very simple backend.
> 
> Replication is via doveadm on a specified port (not SSH). Some output from 
> dovecot -n is below.
> 
> Cheers
> James
> 
> HOST A
> 
> # 2.3.8 (9df20d2db): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.5.8 (b7b03ba2)
> # OS: Linux 4.18.0-193.28.1.el8_2.x86_64 x86_64 CentOS Linux release 8.2.2004 
> (Core)  xfs
> # Hostname: hosta.domain
> auth_mechanisms = plain login
> doveadm_password = # hidden, use -P to show it
> doveadm_port = 4040
> first_valid_uid = 1000
> mail_debug = yes
> mail_home = /srv/vmail/%u
> mail_location = maildir:/srv/vmail/%u
> mail_plugins = notify replication
> managesieve_notify_capability = mailto
> managesieve_sieve_capability = fileinto reject envelope encoded-character 
> vacation subaddress comparator-i;ascii-numeric relational regex imap4flags 
> copy include variables body enotify environment mailbox date index ihave 
> duplicate mime foreverypart extracttext
> mbox_write_locks = fcntl
> namespace inbox {
>  inbox = yes
>  location = 
>  mailbox Drafts {
>auto = subscribe
>special_use = \Drafts
>  }
>  mailbox Junk {
>auto = subscribe
>special_use = \Junk
>  }
>  mailbox Sent {
>special_use = \Sent
>  }
>  mailbox "Sent Messages" {
>special_use = \Sent
>  }
>  mailbox Trash {
>auto = subscribe
>special_use = \Trash
>  }
>  prefix = 
> }
> passdb {
>  args = scheme=BLF-CRYPT username_format=%u /etc/dovecot/users
>  driver = passwd-file
> }
> plugin {
>  mail_replica = tcp:b.b.b.b:4040
>  sieve = file:~/sieve;active=~/.dovecot.sieve
>  sieve_before = /var/mail/SpamToJunk.sieve
> }
> protocols = imap lmtp
> service aggregator {
>  fifo_listener replication-notify-fifo {
>group = root
>mode = 0660
>user = vmail
>  }
>  unix_listener replication-notify {
>group = root
>mode = 0660
>user = vmail
>  }
> }
> service auth {
>  unix_listener /var/spool/postfix/private/auth {
>group = postfix
>mode = 0600
>user = postfix
>  }
> }
> service doveadm {
>  inet_listener {
>port = 4040
>  }
> }
> service lmtp {
>  unix_listener /var/spool/postfix/private/dovecot-lmtp {
>group = postfix
>mode = 0600
>user = postfix
>  }
> }
> service replicator {
>  process_min_avail = 1
>  unix_listener replicator-doveadm {
>mode = 0600
>user = vmail
>  }
> }
> ssl = required
> ssl_cert =  ssl_cipher_list = PROFILE=SYSTEM
> ssl_dh = # hidden, use -P to show it
> ssl_key = # hidden, use -P to show it
> ssl_min_protocol = TLSv1.2
> ssl_prefer_server_ciphers = yes
> userdb {
>  args = username_format=%u /etc/dovecot/users
>  default_fields = uid=vmail gid=mail home=/srv/vmail/%u
>  driver = passwd-file
> }
> protocol lmtp {
>  mail_plugins = sieve
> }
> protocol lda {
>  mail_plugins = notify replication sieve
> }
> 
> HOST B
> 
> # 2.3.8 (9df20d2db): /etc/dovecot/dovecot.conf
> # Pigeonhole version 0.5.8 (b7b03ba2)
> # OS: Linux 4.18.0-193.28.1.el8_2.x86_64 x86_64 CentOS Linux release 8.2.2004 
> (Core)  ext4
> # Hostname: hostb
> auth_mechanisms = plain login
> doveadm_password = # hidden, use -P to show it
> doveadm_port = 4040
> first_valid_uid = 1000
> mail_debug = yes
> mail_home = /srv/vmail/%u
> mail_location = maildir:/srv/vmail/%u
> mail_plugins = notify replication
>

Re: Sieve filter script EXECUTION FAILED

2020-10-31 Thread @lbutlr 
On 30 Oct 2020, at 14:41, Bernd Petrovitsch  wrote:
> Perhaps try the script beforehand in a terminal:

I have. And I use | as delimiters all the time.

>   snip  
> {2}sed -e '|x|y|'
> sed: -e expression #1, char 1: unknown command: `|'
>   snip  
> So no, it's not.

Yes it is. As I said in another post the 's' was lost either in copy/paste or 
possibly in editing,

The shell script works from the command line.

$ echo "" | ./darkmode.sh
* {color:white !important; background-color: black !important; } 



-- 
Well, we know where we're goin' But we don't know where we've been
And we know what we're knowin' But we can't say what we've seen

Odd replication behaviour

2020-10-31 Thread James Pattinson 
Hi,

I have just built a new pair of similar machines both running CentOS 8.2 
(selinux disabled) and Dovecot 2.3.8 (9df20d2db).

One machine is a VPS (host A) and one is on my home network (host B). The idea 
is that they are set up in a master/master config with Dovecot replication.

I seem to have this 95% working but there is one strange issue I can’t work out.

Currently B is a perfect replica of A. I have pointed an instance of 
Thunderbird at it, and I can see all my mails. If I delete any mails or change 
any flags, I see the same changes almost instantly on the A side.

PROBLEM: if host A receives a new mail, I don’t see it on B until I do 
‘something’ to change metadata, for example deleting any random email, or 
marking an email as read on EITHER side causes the new email to appear almost 
instantly on the B side.

I would have expected emails on B to appear immediately. Am I doing something 
wrong?

Extra info -  my mailboxes are in Maildir format with single OS user (vmail). I 
have about 4000 emails in the Inbox and about 30k in other folders.

There are only 5 users and I’m using passdb as the very simple backend.

Replication is via doveadm on a specified port (not SSH). Some output from 
dovecot -n is below.

Cheers
James

HOST A

# 2.3.8 (9df20d2db): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.8 (b7b03ba2)
# OS: Linux 4.18.0-193.28.1.el8_2.x86_64 x86_64 CentOS Linux release 8.2.2004 
(Core)  xfs
# Hostname: hosta.domain
auth_mechanisms = plain login
doveadm_password = # hidden, use -P to show it
doveadm_port = 4040
first_valid_uid = 1000
mail_debug = yes
mail_home = /srv/vmail/%u
mail_location = maildir:/srv/vmail/%u
mail_plugins = notify replication
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character 
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy 
include variables body enotify environment mailbox date index ihave duplicate 
mime foreverypart extracttext
mbox_write_locks = fcntl
namespace inbox {
  inbox = yes
  location = 
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox Junk {
auto = subscribe
special_use = \Junk
  }
  mailbox Sent {
special_use = \Sent
  }
  mailbox "Sent Messages" {
special_use = \Sent
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix = 
}
passdb {
  args = scheme=BLF-CRYPT username_format=%u /etc/dovecot/users
  driver = passwd-file
}
plugin {
  mail_replica = tcp:b.b.b.b:4040
  sieve = file:~/sieve;active=~/.dovecot.sieve
  sieve_before = /var/mail/SpamToJunk.sieve
}
protocols = imap lmtp
service aggregator {
  fifo_listener replication-notify-fifo {
group = root
mode = 0660
user = vmail
  }
  unix_listener replication-notify {
group = root
mode = 0660
user = vmail
  }
}
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0600
user = postfix
  }
}
service doveadm {
  inet_listener {
port = 4040
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
  }
}
service replicator {
  process_min_avail = 1
  unix_listener replicator-doveadm {
mode = 0600
user = vmail
  }
}
ssl = required
ssl_cert =

Re: doveadm sync usage ; root INBOX unsynced

2020-10-31 Thread François Poulain 
Le Sat, 31 Oct 2020 13:36:32 +0100,
François Poulain  a écrit :

> Does someone have on hint?

I tried to remove all dirs and re-start using doveadm backup as did in
https://dovecot.org/pipermail/dovecot/2019-December/117963.html but it
didn't worked better.

François  

-- 
François Poulain

Re: Indexer error after upgrade to 2.3.11.3 [trial patch]

2020-10-31 Thread Scott Q. 
But do you know how this bug was introduced ?

I checked the history of that file and don't see anything introduced
recently that might cause
this: 
https://github.com/dovecot/core/commits/master/src/lib-http/http-client-request.c


The only one that might be somewhat related is this one from Apr 27 by
Stephan Bosch


https://github.com/dovecot/core/commit/799b52accf71e86756dde738d22c1c6a500a7e29#diff-1c02b3481573ffd33c9abccd3f5a6752a5cd81ca83389f4380657f7309c06366




On Saturday, 31/10/2020 at 08:40 John Fawcett wrote:


 On 31/10/2020 00:18, Scott Q. wrote:



 I have implemented this change and the core dumps went away. 

It appears so far that it's indeed the right fix.


Has this change been introduced in 2.3.11.3 ? 


Thanks!


 

I've also been running it for 4 days without any further panics /
segfaults and no noticed adverse effects. I'd recommend the dovecot
team to consider including the patch in the next update.



John



diff -ur dovecot-2.3.11.3-orig/src/lib-http/http-client-request.c
dovecot-2.3.11.3/src/lib-http/http-client-request.c
--- dovecot-2.3.11.3-orig/src/lib-http/http-client-request.c   
2020-08-12 14:20:41.0 +0200
+++ dovecot-2.3.11.3/src/lib-http/http-client-request.c 2020-10-27
13:06:09.352973130 +0100
@@ -1229,12 +1229,12 @@
    const char *error;
    uoff_t offset;

-   i_assert(req->payload_input != NULL);
-   i_assert(req->payload_output != NULL);
-
    if (req->payload_finished)
    return
http_client_request_finish_payload_out(req);

+   i_assert(req->payload_input != NULL);
+   i_assert(req->payload_output != NULL);
+
    io_remove(>io_req_payload);

    /* chunked ostream needs to write to the parent
stream's buffer */

Re: Indexer error after upgrade to 2.3.11.3 [trial patch]

2020-10-31 Thread John Fawcett 
On 31/10/2020 00:18, Scott Q. wrote:
> I have implemented this change and the core dumps went away.
>
> It appears so far that it's indeed the right fix.
>
> Has this change been introduced in 2.3.11.3 ? 
>
> Thanks!

I've also been running it for 4 days without any further panics /
segfaults and no noticed adverse effects. I'd recommend the dovecot team
to consider including the patch in the next update.

John

diff -ur dovecot-2.3.11.3-orig/src/lib-http/http-client-request.c
dovecot-2.3.11.3/src/lib-http/http-client-request.c
--- dovecot-2.3.11.3-orig/src/lib-http/http-client-request.c   
2020-08-12 14:20:41.0 +0200
+++ dovecot-2.3.11.3/src/lib-http/http-client-request.c 2020-10-27
13:06:09.352973130 +0100
@@ -1229,12 +1229,12 @@
    const char *error;
    uoff_t offset;

-   i_assert(req->payload_input != NULL);
-   i_assert(req->payload_output != NULL);
-
    if (req->payload_finished)
    return http_client_request_finish_payload_out(req);

+   i_assert(req->payload_input != NULL);
+   i_assert(req->payload_output != NULL);
+
    io_remove(>io_req_payload);

    /* chunked ostream needs to write to the parent stream's buffer */

doveadm sync usage ; root INBOX unsynced

2020-10-31 Thread François Poulain 
Hi,

I am trying to import a mail IMAP account using doveadm.

Following
https://serverfault.com/questions/605342/migrating-from-any-imap-pop3-server-to-dovecot

I did it with:

doveadm -D -v  \
-o imapc_host=mail.oldserver.tld \
-o imapc_user=cont...@domain.org \
-o imapc_password=xxx \
-o imapc_features=rfc822.size \
-o imapc_ssl=starttls \
-o ssl_client_ca_file=/etc/ssl/certs/ca-certificates.crt \
-o mail_fsync=never \
sync -1 -R -u cont...@domain.org imapc: 

Btw I am facing with exactly the same error than:
https://serverfault.com/questions/960264/doveadm-backup-doesnt-transfer-mail-from-root-inbox

I.e. it works fine for all subfolders, but the root INBOX stay empty on
the new server.

Those debug messages tell me something seems wrong with INBOX root but
I am unable to understand them: 

dsync(cont...@domain.tld): Debug: brain M: Local mailbox tree: INBOX 
guid=deadbeefdeabbeefdeadbeefdeabbeef uid_validity=1604137198 uid_next=1 
subs=no last_change=0 last_subs=0
dsync(cont...@domain.tld): Debug: brain S: Remote mailbox tree: INBOX 
guid=deadbeefdeabbeefdeadbeefdeabbeef uid_validity=1604137198 uid_next=1 
subs=no last_change=0 last_subs=0
dsync(cont...@domain.tld): Debug: brain M: Mailbox INBOX: 
local=deadbeefdeabbeefdeadbeefdeabbeef/0/1, 
remote=/0/0: mailbox not selectable yet
dsync(cont...@domain.tld): Debug: brain S: Mailbox INBOX: 
local=/0/0, 
remote=deadbeefdeabbeefdeadbeefdeabbeef/0/1: mailbox not selectable yet
dsync(cont...@domain.tld): Debug: brain S: Ignore nonexistent mailbox GUID 
deadbeefdeabbeefdeadbeefdeabbeef with -1 sync
dsync(cont...@domain.tld): Debug: brain S: We don't have mailbox 
deadbeefdeabbeefdeadbeefdeabbeef
dsync(cont...@domain.tld): Debug: brain M: Change during sync: Remote lost 
mailbox GUID deadbeefdeabbeefdeadbeefdeabbeef (maybe it was just deleted?)
dsync(cont...@domain.tld): Warning: Mailbox changes caused a desync. You may 
want to run dsync again: Remote lost mailbox GUID 
deadbeefdeabbeefdeadbeefdeabbeef (maybe it was just deleted?)

Does someone have on hint?

Best regards.
François

-- 
François Poulain