isync-devel — All-purpose list, actually - but RTFM first. Moderated for non-subscribers for SPAM protection.

local side is greater than far side

[<sou...@pl...>]

Hi,

I have three systems running mbsync. On some systems, the near side has *more* emails than the far side. I've been using mbsync for years, and this is the first time I've noticed this problem. Possibly related to 1.5.0?

On the broken system, you can see that there are 147 emails (near side), but only 121 on the server (far side).

```
$ mbsync -V --pull foo:INBOX
Reading configuration file /home/username/.mbsyncrc
Channel foo                                                
Opening far side store foo-remote...
Resolving mail.bar.id.au...
Opening near side store foo-local...
Connecting to mail.bar.id.au (<IP_redacted>)... 
Connection is now encrypted
Logging in...
Authenticating with SASL mechanism PLAIN...
Opening far side box INBOX...                                 
Opening near side box INBOX...
Loading far side box...
Loading near side box...
near side: 147 messages, 0 recent
far side: 121 messages, 0 recent
Synchronizing...
Processed 1 box(es) in 1 channel(s),
pulled 0 new message(s) and 0 flag update(s).
```

On the working system, you can see that the near side correctly has 121 emails.

```
$ mbsync -V --pull foo:INBOX
Reading configuration file /home/username/.mbsyncrc
Channel foo                                                
Opening far side store foo-remote...
Resolving mail.bar.id.au...
Opening near side store foo-local...
Connecting to mail.bar.id.au (<IP_redacted>)... 
Connection is now encrypted
Logging in...
Authenticating with SASL mechanism PLAIN...
Opening far side box INBOX...                                 
Opening near side box INBOX...
Loading far side box...
Loading near side box...
near side: 121 messages, 0 recent
far side: 121 messages, 0 recent
Synchronizing...
Processed 1 box(es) in 1 channel(s),
pulled 0 new message(s) and 0 flag update(s),
pushed 0 new message(s) and 0 flag update(s).
```

I tried editing `.mbsyncstate` and setting both `MaxPulledUid` and `MaxPushedUid` to zero on the broken system, but this did not fix the problem. Further, it doesn't seem to be system-specific, because a different mailbox is broken on the "working" system.

Thank you in advance.

Re: New Socket Error

[Henrik F. <fr...@gm...>]

Den tors 7 nov. 2024 kl 09:48 skrev Oswald Buddenhagen via isync-devel <
isy...@li...>:

> On Wed, Nov 06, 2024 at 06:50:39PM +0100, Henrik Frisk wrote:
> >* 126 FETCH (UID 37160  BODY[] {2012973}
> >=== (100000 bytes omitted)
> >=== (100000 bytes omitted)
> >=== (100000 bytes omitted)
> >Socket error: receive buffer full. Probably protocol error.
> >
> are you _sure_ you're running the actual 1.5.0 release?
> i know from the excessively large log that didn't make it to the list
> that you are _not_ running a recent master.
> you wouldn't be the first to have a stale build in PATH ...
>
> Yes, I did have the 1.5.0 release, and I only have one build on this
computer. However, I did a git pull and I now if I run 'mbsync -v' I get
'isync 1.5.0-7-g3c4b5f1' which appears to be the most recent commit in
master and now it works.

I'm really sorry, I should have updated before posting, but thanks for your
time and effort. It appears to be working now! Thank you so much!
/Henrik

Re: New Socket Error

[Oswald B. <osw...@gm...>]

On Wed, Nov 06, 2024 at 06:50:39PM +0100, Henrik Frisk wrote:
>* 126 FETCH (UID 37160  BODY[] {2012973}
>=== (100000 bytes omitted)
>=== (100000 bytes omitted)
>=== (100000 bytes omitted)
>Socket error: receive buffer full. Probably protocol error.
>
are you _sure_ you're running the actual 1.5.0 release?
i know from the excessively large log that didn't make it to the list
that you are _not_ running a recent master.
you wouldn't be the first to have a stale build in PATH ...

if the problem persists with recent master, then cherry-pick
origin/wip/socket-debug and mail me the resulting log.

[commit] branch 'wip/socket-debug' reset

[ossi <os...@us...>]

The branch 'wip/socket-debug', previously at 6eb5cd7, has been rewound
by 3 revision(s) and subsequently fast-forwarded by 537 revision(s) to
d7dc906.

Re: New Socket Error

[Henrik F. <fr...@gm...>]

Den tis 5 nov. 2024 kl 10:37 skrev Oswald Buddenhagen via isync-devel <
isy...@li...>:

> >2024. nov. 2. 11:11:53 Henrik Frisk <fr...@gm...>:
> >> I decided to give this a try again (see my message from April 1).
> >>
> please include an archive link for readers' convenience:
>
> https://sourceforge.net/p/isync/mailman/isync-devel/thread/CAO0LSb6H8trfEJnkP5Va5xvoNg-d6qrBJbrnk_vf0BJWJNUqEQ%40mail.gmail.com/#msg58755349
>
> Yes of course, sorry about that!


> >> I'm using Davmail to connect to a OAuth2 account and mbsync. One of the
> >> accounts work fine, the other not.
> >>
> >> The error I am now getting is this:
> >>
> >> Socket error: receive buffer full. Probably protocol error.
> >
> tracking such errors requires the -Dn log. only the end of it, starting
> with the failing command (identified by the imap tag) being sent out (or
> maybe _a little_ bit more).
>

Is this what you need:

(45 in progress) >>> 51 UID FETCH 37697 (BODY.PEEK[])
(46 in progress) >>> 52 UID FETCH 37698 (BODY.PEEK[])
(47 in progress) >>> 53 UID FETCH 37699 (BODY.PEEK[])
(48 in progress) >>> 54 UID FETCH 37702 (BODY.PEEK[])
(49 in progress) >>> 55 UID FETCH 37704 (BODY.PEEK[])
* 126 FETCH (UID 37160  BODY[] {2012973}
=== (100000 bytes omitted)
=== (100000 bytes omitted)
=== (100000 bytes omitted)
Socket error: receive buffer full. Probably protocol error.
Processed 1 box(es) in 1 channel(s),
pulled 0 new message(s) and 0 flag update(s),
expunged 0 message(s) from near side,
pushed 0 new message(s) and 0 flag update(s),
expunged 0 message(s) from far side.

Best,
/Henrik

>
>
>
> _______________________________________________
> isync-devel mailing list
> isy...@li...
> https://lists.sourceforge.net/lists/listinfo/isync-devel
>

Re: New Socket Error

[Oswald B. <osw...@gm...>]

>2024. nov. 2. 11:11:53 Henrik Frisk <fr...@gm...>:
>> I decided to give this a try again (see my message from April 1).
>>
please include an archive link for readers' convenience:
https://sourceforge.net/p/isync/mailman/isync-devel/thread/CAO0LSb6H8trfEJnkP5Va5xvoNg-d6qrBJbrnk_vf0BJWJNUqEQ%40mail.gmail.com/#msg58755349

>> I'm using Davmail to connect to a OAuth2 account and mbsync. One of the
>> accounts work fine, the other not.
>>
>> The error I am now getting is this:
>>
>> Socket error: receive buffer full. Probably protocol error.
>
tracking such errors requires the -Dn log. only the end of it, starting
with the failing command (identified by the imap tag) being sent out (or
maybe _a little_ bit more).

On Sat, Nov 02, 2024 at 11:37:17AM +0100, Bence Ferdinandy wrote:
>My post is a bit out of date wrt isync, but for davmail I needed to
>drop a commit to make it work:
>
>https://bence.ferdinandy.com/2023/07/20/email-in-the-terminal-a-complete-guide-to-the-unix-way-of-email/#building-from-source
>
that issue is already fixed properly in the meanwhile released 1.5.0.

Re: New Socket Error

[Bence F. <be...@fe...>]

2024. nov. 2. 11:11:53 Henrik Frisk <fr...@gm...>:

> hi,
>
> I decided to give this a try again (see my message from April 1).
>
> I'm using Davmail to connect to a OAuth2 account and mbsync. One of the
> accounts work fine, the other not.
>
> The error I am now getting is this:
>
> Socket error: receive buffer full. Probably protocol error.

My post is a bit out of date wrt isync, but for davmail I needed to drop 
a commit to make it work:

https://bence.ferdinandy.com/2023/07/20/email-in-the-terminal-a-complete-guide-to-the-unix-way-of-email/#building-from-source


>
> thanks for any hints!
>
> /Henrik
>
> _______________________________________________
> isync-devel mailing list
> isy...@li...
> https://lists.sourceforge.net/lists/listinfo/isync-devel

New Socket Error

[Henrik F. <fr...@gm...>]

hi,

I decided to give this a try again (see my message from April 1).

I'm using Davmail to connect to a OAuth2 account and mbsync. One of the
accounts work fine, the other not.

The error I am now getting is this:

Socket error: receive buffer full. Probably protocol error.

thanks for any hints!

/Henrik

[PATCH] build: also consider builds off of git with `git clone --depth 1`

[Paymon M. <dar...@gm...>]

Signed-off-by: Paymon MARANDI <dar...@gm...>
---
 version.sh | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/version.sh b/version.sh
index fc1ed7d..8759e3f 100755
--- a/version.sh
+++ b/version.sh
@@ -18,6 +18,11 @@ fi
 if test -z "$mb"; then
 	# still no upstream, so just describe HEAD as-is.
 	gver=$(git describe --tags HEAD)
+	# one case this could happen is a shallow clone, purely for build
+	# purposes
+	if test -z "$gver"; then
+		gver="git-shallow"
+	fi
 else
 	# find out whether we have local work, and if so, collapse it into
 	# a single suffix. otherwise, we'd cause pointless rebuilds during
-- 
2.47.0

Re: Error: AltMap=true is not supported by this build

[Britt A. <br...@b3...>]

pacman -S db does not fix the problem for version -2; all still works
fine on version -1.

I will just pin pacman to this version for now.

I don't mind trying to debug this further, but if I am the only person
in the world with this problem, and I have a simple work around, it does
not seem worth your time to me to pursue this further. Thank you both
for the timely responses. 

Norbert Preining <no...@pr...>
writes:

> Hi Britt,
>
> On Tue, 29 Oct 2024, Oswald Buddenhagen via isync-devel wrote:
>> > On upgrading from isync 1.5.0.1 to 1.5.0.2 I now get this message. I am
>> > using the ArchLinux package. I do have an AltMap yes in my config. On
>> > downgrading to 1.5.0.1 everything works fine.
>
> The version numbers are
> 	1.5.0-1 to 1.5.0-2
> and the only change from -1 to -2 is this:
> https://gitlab.archlinux.org/archlinux/packaging/packages/isync/-/commit/a4cfee9d04627a33625cabff767db89b8ff0fec5
> which removes the dependency on 'db'.
>
> Can you install the db package and see if that fixes it?
>
> If not, something else is broken, because there are no other changes.
>
> Best regards
>
> Norbert
> (not the isync maintainer in arch, just heavy user of it ;-)


-- 
Britt Anderson
Kitchener, ON CA

Re: Error: AltMap=true is not supported by this build

[Norbert P. <no...@pr...>]

Hi Britt,

On Tue, 29 Oct 2024, Oswald Buddenhagen via isync-devel wrote:
> > On upgrading from isync 1.5.0.1 to 1.5.0.2 I now get this message. I am
> > using the ArchLinux package. I do have an AltMap yes in my config. On
> > downgrading to 1.5.0.1 everything works fine.

The version numbers are
	1.5.0-1 to 1.5.0-2
and the only change from -1 to -2 is this:
https://gitlab.archlinux.org/archlinux/packaging/packages/isync/-/commit/a4cfee9d04627a33625cabff767db89b8ff0fec5
which removes the dependency on 'db'.

Can you install the db package and see if that fixes it?

If not, something else is broken, because there are no other changes.

Best regards

Norbert
(not the isync maintainer in arch, just heavy user of it ;-)

--
PREINING Norbert                              https://www.preining.info
arXiv / Cornell University   +   IFMGA Guide   +   TU Wien  +  TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: Error: AltMap=true is not supported by this build

[Oswald B. <osw...@gm...>]

On Tue, Oct 29, 2024 at 08:30:47AM -0400, Britt Anderson wrote:
>On upgrading from isync 1.5.0.1 to 1.5.0.2 I now get this message. I am
>using the ArchLinux package. I do have an AltMap yes in my config. On
>downgrading to 1.5.0.1 everything works fine.
>
given that these versions don't even exist upstream, you're facing a
packaging bug. please report this issue to arch.

Error: AltMap=true is not supported by this build

[Britt A. <br...@b3...>]

On upgrading from isync 1.5.0.1 to 1.5.0.2 I now get this message. I am
using the ArchLinux package. I do have an AltMap yes in my config. On
downgrading to 1.5.0.1 everything works fine.

I looked at the NEWS file, but I didn't see anything documented about
this change. I know the default for AltMap was NO and I frankly don't
remember why I set this in my config ages ago.

Would be happy to delete it if that is known to be okay. Or maybe
someone can share what the change was?

Thank you,

Re: Issues with Exchange Online.

[Oswald B. <osw...@gm...>]

On Mon, Oct 14, 2024 at 03:16:36PM +0100, Dom (shymega) Rodriguez wrote:
>On 23.09.2024 10:34, Oswald Buddenhagen via isync-devel wrote:
>>On Sun, Sep 22, 2024 at 06:09:06PM +0200, Dom (shymega) Rodriguez wrote:
>>>As well as that, I find OWA has the dates in the wrong order after
>>>syncing. I have `CopyArrivalDates` set as true.
>>>
>>you mean, the pull causes the server to re-stamp the messages? that's
>>just weird ...
>
>It happens after a fresh sync. I have to re-stamp the messages.
>
i still don't understand what _exactly_ the problem is.
try the formal "what did i do / what did i expect / what did actually
happen" format, for each weirdness separately, in as far as possible.

>Basically, my setup is:
>
>Exchange IMAP <=> mbsync <=> local IMAP (Dovecot) <=> MUA (Neomutt).
>
that's just fine. the rewrite from isync to mbsync was done with such a
configuration explicitly in mind.

>>mail them to me privately.
>
>Which logs do you need? I.e, in terms of `-D` flags. I have to be
>careful with providing raw email data, though.
>
the -D log won't reveal anything personal that the -V log you already
sent didn't. only -DN would take it to the next level.

the log should be from a single (small) channel:box, as otherwise i'll
completely drown in noise. and make sure that it actually includes
propagation of fresh affected messages. ideally, blow away the copy _and
the corresponding sync state_ of a small folder and re-sync it from
scratch.

in the previous log, we see this:
>
>IMAP command 'NAMESPACE' returned an error: User is authenticated but not connected.
>
which is just weird.
to debug this, we need the -Dn log from that channel.

>>>I've tried the `wip/exchange-workarounds-1.5` branch on NixOS, which
>>>produced a segfault. I can get a backtrace if needed.
>>>
>>won't hurt, and valgrind'ing would be even better. just make sure the
>>build has debug symbols, as otherwise the traces will be completely
>>useless.
>>however, the branch isn't really expected to work, as it's untested; i
>>had no access to exchange for half a decade. and even in the best case,
>>it contains some rather egregious hacks.
>
>I had to rebase it, but the segfaults
>prevent it from working so far.

>Which Exchange version were you targeting on that branch?
>
none, as i didn't write it.
check the list archive (or maybe the bug tracker - i don't remember) -
maybe you'll find something.
but i don't think you'd find anything particularly interesting, as it
will be ancient by now anyway.

Re: Issues with Exchange Online.

[Dom (s. R. <sh...@sh...>]

Hi Oswald,

On 23.09.2024 10:34, Oswald Buddenhagen via isync-devel wrote:
>On Sun, Sep 22, 2024 at 06:09:06PM +0200, Dom (shymega) Rodriguez wrote:
>>As well as that, I find OWA has the dates in the wrong order after
>>syncing. I have `CopyArrivalDates` set as true.
>>
>you mean, the pull causes the server to re-stamp the messages? that's
>just weird ...

It happens after a fresh sync. I have to re-stamp the messages.
Basically, my setup is:

Exchange IMAP <=> mbsync <=> local IMAP (Dovecot) <=> MUA (Neomutt).

I prefer hosting my own local IMAP server, but yeah, it's a bit
annoying.

>
>>I'm not sure how comfortable I am sharing the config and more verbose
>>logs via a public mailing list, though.
>>
>mail them to me privately.

Which logs do you need? I.e, in terms of `-D` flags. I have to be
careful with providing raw email data, though.

>>I've tried the `wip/exchange-workarounds-1.5` branch on NixOS, which
>>produced a segfault. I can get a backtrace if needed.
>>
>won't hurt, and valgrind'ing would be even better. just make sure the
>build has debug symbols, as otherwise the traces will be completely
>useless.
>however, the branch isn't really expected to work, as it's untested; i
>had no access to exchange for half a decade. and even in the best case,
>it contains some rather egregious hacks.

I had to rebase it, but the segfaults
prevent it from working so far. Which Exchange version were you
targeting on thsat branch?

>
>>Would it be better to use Davmail?
>>
>probably not.

I've run into a bug with Davmail, but I'm not sure if it's related to
mbsync.

Basically, when syncing a shared inbox via my main account, the shared
inbox's messages get copied into the main account. I'll share that
config with you too.

Best wishes,
--
Dom Rodriguez
GPG Fingerprint: EB0D 45E6 D0DC 1BA1 A2B5  FC24 72DC F123 1E54 BD43

Re: Issues with Exchange Online.

[Dom (s. R. <sh...@sh...>]

Hi,

Oswald - I saw your reply on the archives, but I'm afraid it didn't make
it through to me. I am subscribed to the list.

Would you be able to resend, and email me directly, so I can reply with
the logs?

Thanks.

On 22.09.2024 18:09, Dom (shymega) Rodriguez wrote:
>Hello,
>
>I'm using `isync` with Microsoft 365 directly, via XOAUTH2/IMAP,
>however, I'm running into issues.
>
>The main issue is from the attached log, but I'm also finding that when
>I restore deleted emails via OWA, and sync, they're deleted again. This
>happens even when running `mbsync -L $account`.
>
>As well as that, I find OWA has the dates in the wrong order after
>syncing. I have `CopyArrivalDates` set as true.
>
>I'm not sure how comfortable I am sharing the config and more verbose
>logs via a public mailing list, though.
>
>I've tried the `wip/exchange-workarounds-1.5` branch on NixOS, which
>produced a segfault. I can get a backtrace if needed.
>
>Would it be better to use Davmail?
>
>Thank you.
>
>Best wishes,
>--
>Dom Rodriguez
>GPG Fingerprint: EB0D 45E6 D0DC 1BA1 A2B5  FC24 72DC F123 1E54 BD43

>Error: far side refuses to store message 72 from near side.
>Error: far side refuses to store message 1 from near side.



Best wishes,
--
Dom Rodriguez
GPG Fingerprint: EB0D 45E6 D0DC 1BA1 A2B5  FC24 72DC F123 1E54 BD43

Re: Specific mailbox is not synchronized

[Oswald B. <osw...@gm...>]

On Tue, Oct 08, 2024 at 09:40:43AM +0200, Jan Eden via isync-devel wrote:
>Is there anything I can do to debug?
>
when you report problems, always include your config file.

as a first test, try `mbsync -l ...` to see which boxes isync thinks are
present.

if it's there, search the list archive for "MaxPulledUid".

but before you even start, upgrade to git master (which is 1.5.0 plus a
few followup fixes i really should release soon).

Re: Re: Specific mailbox is not synchronized

[Jan E. <te...@ed...>]

On 2024-10-08 13:13, Jan Eden wrote:

> On 2024-10-08 09:40, Jan Eden via isync-devel wrote:

> > Hi,
> > 
> > I synchronize a mail account with very few (large) mailboxes on two
> > machines using isync/mbsync. Each mailbox contains messages from a
> > single year, with 'Archive' being used for the current year.
> > 
> > After the initial sync on the second machine (with isync 1.4.4), I ended
> > up with ~ 6800 messages instead of ~ 8400 messages in Archive, while the
> > older mailboxes (> 10,000 messages each) were synchronized entirely.
> > 
> > Although each sync completes without errors and takes 'Archive' into
> > account (according to the output in debug mode), the 'Archive' mailbox
> > seems to be detached from the far side, and if I manually copy messages
> > to 'Archive' on the second machine, they are not propagated to the
> > server.
> > 
> > The Inbox is synchronized properly.
> > 
> > Is there anything I can do to debug?
> 
> I misinterpreted the issue, which occurs on the *first* machine. This is
> what happens in debug mode:
> 
> (1 in progress) F: >>> 21 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:05:10 +0200" {51748+}
> F: >>>>> (51748 bytes omitted)
> (2 in progress) F: >>> 22 APPEND "Archive" (\Seen) "16-Aug-2024 15:12:15 +0200" {8573+}
> F: >>>>> (8573 bytes omitted)
> (3 in progress) F: >>> 23 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:49:37 +0200" {19318+}
> F: >>>>> (19318 bytes omitted)
> (4 in progress) F: >>> 24 APPEND "Archive" (\Seen) "16-Aug-2024 16:06:59 +0200" {33803+}
> F: >>>>> (33803 bytes omitted)
> (5 in progress) F: >>> 25 APPEND "Archive" (\Seen) "16-Aug-2024 17:04:37 +0200" {40036+}
> F: >>>>> (40036 bytes omitted)
> F:  BAD Command Error. 10
> F: Callback enter bad store
> F: Enter cancel_store
> F: [ 34] Callback enter store_msg, sts=4
> 
> When deleting the message with the timestamp 16-Aug-2024 17:04:37 and a
> second one received immediately afterwards, this happens:
> 
> (1 in progress) F: >>> 21 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:05:10 +0200" {51748+}
> F: >>>>> (51748 bytes omitted)
> (2 in progress) F: >>> 22 APPEND "Archive" (\Seen) "16-Aug-2024 15:12:15 +0200" {8573+}
> F: >>>>> (8573 bytes omitted)
> (3 in progress) F: >>> 23 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:49:37 +0200" {19318+}
> F: >>>>> (19318 bytes omitted)
> (4 in progress) F: >>> 24 APPEND "Archive" (\Seen) "16-Aug-2024 16:06:59 +0200" {33803+}
> F: >>>>> (33803 bytes omitted)
> (5 in progress) F: >>> 25 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 15:26:31 +0200" {30991+}
> F: >>>>> (30991 bytes omitted)

Sorry, incomplete extract from the log:

(1 in progress) F: >>> 21 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:05:10 +0200" {51748+}
F: >>>>> (51748 bytes omitted)
(2 in progress) F: >>> 22 APPEND "Archive" (\Seen) "16-Aug-2024 15:12:15 +0200" {8573+}
F: >>>>> (8573 bytes omitted)
(3 in progress) F: >>> 23 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:49:37 +0200" {19318+}
F: >>>>> (19318 bytes omitted)
(4 in progress) F: >>> 24 APPEND "Archive" (\Seen) "16-Aug-2024 16:06:59 +0200" {33803+}
F: >>>>> (33803 bytes omitted)
(5 in progress) F: >>> 25 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 15:26:31 +0200" {30991+}
F: >>>>> (30991 bytes omitted)
F:  BAD Command Error. 10
F: Callback enter bad store
F: Enter cancel_store
F: [ 34] Callback enter store_msg, sts=4
> 
> Is there any way to link the error (which manifests as `IMAP error:
> unexpected tag BAD` during regular operation) to a specific message, or
> to some other known issue with the (Exchange) server?
> 
> - Jan

Re: Specific mailbox is not synchronized

[Jan E. <te...@ed...>]

On 2024-10-08 09:40, Jan Eden via isync-devel wrote:

> Hi,
> 
> I synchronize a mail account with very few (large) mailboxes on two
> machines using isync/mbsync. Each mailbox contains messages from a
> single year, with 'Archive' being used for the current year.
> 
> After the initial sync on the second machine (with isync 1.4.4), I ended
> up with ~ 6800 messages instead of ~ 8400 messages in Archive, while the
> older mailboxes (> 10,000 messages each) were synchronized entirely.
> 
> Although each sync completes without errors and takes 'Archive' into
> account (according to the output in debug mode), the 'Archive' mailbox
> seems to be detached from the far side, and if I manually copy messages
> to 'Archive' on the second machine, they are not propagated to the
> server.
> 
> The Inbox is synchronized properly.
> 
> Is there anything I can do to debug?

I misinterpreted the issue, which occurs on the *first* machine. This is
what happens in debug mode:

(1 in progress) F: >>> 21 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:05:10 +0200" {51748+}
F: >>>>> (51748 bytes omitted)
(2 in progress) F: >>> 22 APPEND "Archive" (\Seen) "16-Aug-2024 15:12:15 +0200" {8573+}
F: >>>>> (8573 bytes omitted)
(3 in progress) F: >>> 23 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:49:37 +0200" {19318+}
F: >>>>> (19318 bytes omitted)
(4 in progress) F: >>> 24 APPEND "Archive" (\Seen) "16-Aug-2024 16:06:59 +0200" {33803+}
F: >>>>> (33803 bytes omitted)
(5 in progress) F: >>> 25 APPEND "Archive" (\Seen) "16-Aug-2024 17:04:37 +0200" {40036+}
F: >>>>> (40036 bytes omitted)
F:  BAD Command Error. 10
F: Callback enter bad store
F: Enter cancel_store
F: [ 34] Callback enter store_msg, sts=4

When deleting the message with the timestamp 16-Aug-2024 17:04:37 and a
second one received immediately afterwards, this happens:

(1 in progress) F: >>> 21 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:05:10 +0200" {51748+}
F: >>>>> (51748 bytes omitted)
(2 in progress) F: >>> 22 APPEND "Archive" (\Seen) "16-Aug-2024 15:12:15 +0200" {8573+}
F: >>>>> (8573 bytes omitted)
(3 in progress) F: >>> 23 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 16:49:37 +0200" {19318+}
F: >>>>> (19318 bytes omitted)
(4 in progress) F: >>> 24 APPEND "Archive" (\Seen) "16-Aug-2024 16:06:59 +0200" {33803+}
F: >>>>> (33803 bytes omitted)
(5 in progress) F: >>> 25 APPEND "Archive" (\Answered \Seen) "16-Aug-2024 15:26:31 +0200" {30991+}
F: >>>>> (30991 bytes omitted)

Is there any way to link the error (which manifests as `IMAP error:
unexpected tag BAD` during regular operation) to a specific message, or
to some other known issue with the (Exchange) server?

- Jan

Specific mailbox is not synchronized

[Jan E. <te...@ed...>]

Hi,

I synchronize a mail account with very few (large) mailboxes on two
machines using isync/mbsync. Each mailbox contains messages from a
single year, with 'Archive' being used for the current year.

After the initial sync on the second machine (with isync 1.4.4), I ended
up with ~ 6800 messages instead of ~ 8400 messages in Archive, while the
older mailboxes (> 10,000 messages each) were synchronized entirely.

Although each sync completes without errors and takes 'Archive' into
account (according to the output in debug mode), the 'Archive' mailbox
seems to be detached from the far side, and if I manually copy messages
to 'Archive' on the second machine, they are not propagated to the
server.

The Inbox is synchronized properly.

Is there anything I can do to debug?

- Jan

[commit] master: remove stray closing brace from man page

[ossi <os...@us...>]

commit 3c4b5f1c83a568f18c14c93aab95c9a853edfd15
Author:     Ludovico Gerardi <lud...@po...>
AuthorDate: Sun Sep 29 14:46:39 2024 +0200
Commit:     Oswald Buddenhagen <os...@us...>
CommitDate: Sun Sep 29 14:48:01 2024 +0200

    remove stray closing brace from man page
    
    amends 5d5e07eb.

 src/mbsync.1.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mbsync.1.in b/src/mbsync.1.in
index f950b3b..fba3669 100644
--- a/src/mbsync.1.in
+++ b/src/mbsync.1.in
@@ -12,7 +12,7 @@ mbsync - synchronize IMAP4 and Maildir mailboxes
 .SH SYNOPSIS
 \fBmbsync\fR [\fIoptions\fR ...] {{\fIchannel\fR[\fB:\fIbox\fR[{\fB,\fR|\fB\\n\fR}...]]|\fIgroup\fR} ...|\fB-a\fR}
 .br
-\fBmbsync\fR --list-stores [\fIoptions\fR ...] [\fIstore\fR} ...]
+\fBmbsync\fR --list-stores [\fIoptions\fR ...] [\fIstore\fR ...]
 .
 .SH DESCRIPTION
 \fBmbsync\fR is a command line application which synchronizes mailboxes;

[commit] branch 'master' rewound

[ossi <os...@us...>]

The branch 'master', previously at f7c5f1d, has been rewound by 2
revision(s) to 8c781d4.

[commit] master: remove stray closing brace from man page

[ossi <os...@us...>]

commit f7c5f1dbf428deb9686d5d86fd8987af92ec3206
Author:     Ludovico Gerardi <lud...@po...>
AuthorDate: Sun Sep 29 14:46:39 2024 +0200
Commit:     Oswald Buddenhagen <os...@us...>
CommitDate: Sun Sep 29 14:46:39 2024 +0200

    remove stray closing brace from man page
    
    amends 5d5e07eb.

 src/mbsync.1.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mbsync.1.in b/src/mbsync.1.in
index f950b3b..fba3669 100644
--- a/src/mbsync.1.in
+++ b/src/mbsync.1.in
@@ -12,7 +12,7 @@ mbsync - synchronize IMAP4 and Maildir mailboxes
 .SH SYNOPSIS
 \fBmbsync\fR [\fIoptions\fR ...] {{\fIchannel\fR[\fB:\fIbox\fR[{\fB,\fR|\fB\\n\fR}...]]|\fIgroup\fR} ...|\fB-a\fR}
 .br
-\fBmbsync\fR --list-stores [\fIoptions\fR ...] [\fIstore\fR} ...]
+\fBmbsync\fR --list-stores [\fIoptions\fR ...] [\fIstore\fR ...]
 .
 .SH DESCRIPTION
 \fBmbsync\fR is a command line application which synchronizes mailboxes;

[commit] master: mbsync-get-cert: add support for STARTTLS

[ossi <os...@us...>]

commit 33bb58b3b3c27dbc0d09c4ce8008ca9c6ea6ee99
Author:     Behnam Lal <de...@be...>
AuthorDate: Sun Sep 29 14:35:11 2024 +0200
Commit:     Oswald Buddenhagen <os...@us...>
CommitDate: Sun Sep 29 14:36:30 2024 +0200

    mbsync-get-cert: add support for STARTTLS
    
    nowadays, many servers offer STARTTLS on the default IMAP port 143
    instead of (or in addition to) the traditional IMAP over SSL/TLS (IMAPS)
    on port 993.
    
    this patch has been fixed up somewhat by the maintainer.

 mbsync-get-cert | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/mbsync-get-cert b/mbsync-get-cert
index 19e1485..d8f194a 100755
--- a/mbsync-get-cert
+++ b/mbsync-get-cert
@@ -9,9 +9,25 @@
 # from a trusted source.
 #
 
-if [ $# != 1 ]; then
-	echo "Usage: $0 <host>" >&2
+usage() {
+	echo "Usage: $0 [-s] <host>" >&2
+	echo "  -s        Use IMAP+STARTTLS (port 143) instead of IMAPS (port 993)" >&2
 	exit 1
+}
+
+STARTTLS=false
+
+while getopts "s" opt; do
+	case $opt in
+	s) STARTTLS=true ;;
+	*) usage ;;
+	esac
+done
+
+shift `expr $OPTIND - 1`
+
+if [ $# -ne 1 ]; then
+	usage
 fi
 
 HOST=$1
@@ -33,7 +49,15 @@ TMPFILE=$TMPDIR/get-cert
 ERRFILE=$TMPDIR/get-cert-err
 CERTFILE=$TMPDIR/cert
 
-echo QUIT | openssl s_client -connect $HOST:993 -showcerts \
+if $STARTTLS; then
+	FLAGS="-starttls imap"
+	PORT=143
+else
+	FLAGS=
+	PORT=993
+fi
+
+echo QUIT | openssl s_client $FLAGS -connect $HOST:$PORT -showcerts \
 	> $TMPFILE 2> $ERRFILE
 sed -e '1,/^-----BEGIN CERTIFICATE-----/d' \
 	-e '/^-----END CERTIFICATE-----/,$d' < $TMPFILE > $CERTFILE

Re: #20 [PATCH] add(mbsync-get-cert): support STARTTLS and custom port

[Oswald B. <osw...@gm...>]

On Sun, Sep 29, 2024 at 12:18:14PM +0000, Behnam Lal Moghaddam wrote:
>I just didn't bother to change the name ever, so that pseudonym has
>been used more often than my real name.
>
heh, ok.

i made a few fixups. unless you see something wrong with it, i'll push
this version at some point.