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

[PATCH] Fix typo

[Ludovico G. <lud...@po...>]

Signed-off-by: Ludovico Gerardi <lud...@po...>
---
 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;
-- 
2.46.2

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

[Behnam L. M. <beh...@gm...>]

On 24/09/29 12:07PM, Oswald Buddenhagen via isync-devel wrote:
> however, i don't quite get this:
> > From: CheesyChocolate <de...@be...>
> > signed-off-by: CheesyChocolate <de...@be...>
> >
> why are you using this pseudonym for the commits when you're using an
> apparent real name on the list?
I made a new patch with my real name. I'm sorry for the confusion. I
just didn't bother to change the name ever, so that pseudonym has been
used more often than my real name.

-- 
Behnam Lal
in...@be...
behnamlal.xyz

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

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

On Sat, Sep 28, 2024 at 11:54:56PM +0000, Behnam Lal Moghaddam wrote:
>On 24/09/28 02:03PM, Oswald Buddenhagen via isync-devel wrote:
>> a few suggestions:
>>
>I rewrote the patch according to your suggestions.
>
ok. i see you removed the port config entirely, which is fair enough.

however, i don't quite get this:
>From: CheesyChocolate <de...@be...>
>signed-off-by: CheesyChocolate <de...@be...>
>
why are you using this pseudonym for the commits when you're using an
apparent real name on the list?

Re: Convert from mutt record file to mbsync file with proper UID

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

On Sat, Sep 28, 2024 at 05:17:55PM +0000, Ludovico Gerardi wrote:
>The problem is that I still have the older outgoing messages in the
>renamed file, and I don't know how to convert those into the format that
>mbsync uses, with the right UID etc. Could anyone help me please?
>
you don't need to worry about the UIDs.

it's easiest to just open the folder with mutt and then `save` the
messages to the right one.

for a mass conversion to maildir, `formail -s` would be the tool of
choice.

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

[Behnam L. M. <beh...@gm...>]

On 24/09/28 02:03PM, Oswald Buddenhagen via isync-devel wrote:
> On Sat, Sep 28, 2024 at 09:23:49AM +0000, Behnam Lal Moghaddam wrote:
> > I want to share a patch that allows mbsync-get-cert script to support
> > STARTTLS and custom port.
> >
> thanks!
>
> a few suggestions:
> - use true/false for $STARTTLS - then you can evaluate it without
>   running it through `test`
> - don't default the port - then you can make it fall back depending on
>   $STARTTLS, which would make specifying a port generally unnecessary
> - a signed-off-by footer is optional here, but make sure that the author
>   info is sane and matches S-O-B if present
>
I rewrote the patch according to your suggestions. the new patch is attached. to this mail.
> i'm pondering whether i should classify this omission as a bug and
> therefore apply this for 1.5.1. strictly speaking, it's a feature, so
> material for master ...
>
I do agree that this counts as a feature. Either way, since it's not a huge change, I think it's safe to include it in the next release.
>
>
> _______________________________________________
> isync-devel mailing list
> isy...@li...
> https://lists.sourceforge.net/lists/listinfo/isync-devel

-- 
Behnam Lal
in...@be...
behnamlal.xyz

Convert from mutt record file to mbsync file with proper UID

[Ludovico G. <lud...@po...>]

Hello,

before running mbsync for the first time I had setup neomutt with the
'record' option set to 'Sent', and neomutt created a file called 'Sent'
within the mail directory, where it appended outgoing messages. However
that meant I could not sync those messages with mbsync, so I renamed the
file and run mbsync, which created a 'Sent' folder, and now new outgoing
messages are being synchronized.

The problem is that I still have the older outgoing messages in the
renamed file, and I don't know how to convert those into the format that
mbsync uses, with the right UID etc. Could anyone help me please?
-- 
Regards,
Ludovico Gerardi

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

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

On Sat, Sep 28, 2024 at 09:23:49AM +0000, Behnam Lal Moghaddam wrote:
>I want to share a patch that allows mbsync-get-cert script to support
>STARTTLS and custom port.
>
thanks!

a few suggestions:
- use true/false for $STARTTLS - then you can evaluate it without
   running it through `test`
- don't default the port - then you can make it fall back depending on
   $STARTTLS, which would make specifying a port generally unnecessary
- a signed-off-by footer is optional here, but make sure that the author
   info is sane and matches S-O-B if present

i'm pondering whether i should classify this omission as a bug and
therefore apply this for 1.5.1. strictly speaking, it's a feature, so
material for master ...

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

[Behnam L. M. <beh...@gm...>]

Hello,

I want to share a patch that allows mbsync-get-cert script to support
STARTTLS and custom port. I tried to keep the changes as minimal as
possible, even using legacy shell syntax as it's used in the original script.

The example usage is as follows:

```
mbsync-get-cert -s -p 143 mail.example-domain.org
```
This will connect to mail.example-domain.org on port 143 and use STARTTLS.

The patch will not break the existing functionality, so it's safe to apply.

The patch is attached to this email.

Best regards,

-- 
Behnam Lal
in...@be...
behnamlal.xyz

Re: Issues with Exchange Online.

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

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 ...

>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.

>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.

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

Issues with Exchange Online.

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

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

Re: Not all messages syncing

[Edd B. <ed...@th...>]

Hey,

On Fri, Sep 20, 2024 at 04:31:18PM +0200, Oswald Buddenhagen via isync-devel wrote:
> do you have .journal files next to the state files? then it's actually
> crashing.

No journal files present.

> regardless, please add -D to the command line, sync _one_ affected box,
> and mail me the log.

I'll mail it privately to save me time in eliding addresses etc.

> btw, are you running 1.5.0 already?

Yep. I'm using the OpenBSD package in OpenBSD-current.

There are a handful of patches applied, but none look relevant:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/mail/isync/patches/?hideattic=1#dirlist

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Not all messages syncing

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

On Fri, Sep 20, 2024 at 11:55:19AM +0100, Edd Barrett wrote:
>And if you re-run it again, I see the same discrepancy between the
>mesage
>counts on hte near and far sides. So it's still not syncing.
>
>After those two runs, I notice that MaxPulledUid and MaxPushedUid remain zero.
>Is that right?
>
iirc, no.

do you have .journal files next to the state files? then it's actually
crashing.

regardless, please add -D to the command line, sync _one_ affected box,
and mail me the log.

btw, are you running 1.5.0 already?

Re: Not all messages syncing

[Edd B. <ed...@th...>]

Hi,

Thanks for getting back to me.

On Fri, Sep 20, 2024 at 11:19:31AM +0200, Oswald Buddenhagen via isync-devel wrote:
> resetting the max uids in the state files is a better idea.

I reset (set to 0) MaxPulledUid and MaxPushedUid in INBOX/.mbsyncstate then
re-ran mbsync with -V.

```
...
Opening far side box INBOX...
Opening near side box INBOX...
Loading far side box...
Loading near side box...
near side: 5846 messages, 7 recent
far side: 5839 messages, 0 recent
Synchronizing...
...
```

And if you re-run it again, I see the same discrepancy between the mesage
counts on hte near and far sides. So it's still not syncing.

After those two runs, I notice that MaxPulledUid and MaxPushedUid remain zero.
Is that right?

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: Not all messages syncing

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

On Fri, Sep 20, 2024 at 09:04:57AM +0100, Edd Barrett wrote:
>However I notice that after a sync, mailboxes can be of differing sizes
>on
>different hosts. For example last night, the Inbox folder had:
>
> - 5826 messages on the IMAP server
> - 5860 messages on the desktop
> - 5833 messages on the laptop
>
>What am I missing? Shouldn't all the hosts have the same mail? Is there a way
>to make it so? It's making me a little nervous, because I may be missing mail.
>
sounds like another instance of the MaxPulledUID issue, which was raised
again just a week ago here. related post:
https://www.reddit.com/r/commandline/comments/1d9ik8a/comment/lmwd4l2/

only that in your case it seems to be about the complementary
MaxPushedUID (or possibly both).

>Should I try blasting the sync state files and re-syncing? Is that safe?
>
you mean _just_ the state files?
it's safe, but not recommended, as you'll get duplicates of just about
every mail. you can eliminate them easily using f.ex. mutt, but it's a
tad wasteful.

resetting the max uids in the state files is a better idea.

Not all messages syncing

[Edd B. <ed...@th...>]

Hi,

I was reviewing my email setup, and noticed something I didn't expect.

First, the setup looks like this:

    desktop <---> IMAP server <---> laptop

Both the desktop and laptop have an identical isync config like this:

```
IMAPAccount myaccount
Host <the-server-address>
User <the-user>
PassCmd <the-pass-cmd>
TLSType IMAPS
PipelineDepth 4

IMAPStore myaccount-remote
Account myaccount

MaildirStore myaccount-local
SubFolders Verbatim
Path <the-path>
Inbox <inbox-path>

Channel myaccount
Far :myaccount-remote:
Near :myaccount-local:
Patterns *
Create Both
SyncState *
```

Then I sync with `mbsync -a`.

The intention being that if the desktop and laptop were to sync at the same
moment (and no new mail came in in the meantime), all hosts would have
identical mail.

However I notice that after a sync, mailboxes can be of differing sizes on
different hosts. For example last night, the Inbox folder had:

 - 5826 messages on the IMAP server
 - 5860 messages on the desktop
 - 5833 messages on the laptop

What am I missing? Shouldn't all the hosts have the same mail? Is there a way
to make it so? It's making me a little nervous, because I may be missing mail.

Should I try blasting the sync state files and re-syncing? Is that safe?

Cheers

-- 
Best Regards
Edd Barrett

https://www.theunixzoo.co.uk

Re: near side box '&AOE' cannot be opened

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

On Sat, Sep 14, 2024 at 01:20:25PM +0200, Tamás Gulácsi via isync-devel wrote:
> Patterns "!Trash !Conversation !Deleted !Drafts !Junk !Outbox !RSS !Scheduled"
> Patterns "!\"Conversation History\" !\"Deleted Items\""
> Patterns "!\"Junk Email\""
> Patterns "!\"RSS Feeds\""
>
fwiw, you have a level of quoting too much there.

>What I've configure wrong?
>
nothing in this regard, but you need to upgrade to 1.5.0 for proper
support for non-ascii box names.

make sure to clean up properly, as you apparently have duplicate folders
at this point. the Mag&AOE-n is due to older isync's failure to decode
utf-7 properly, and you shouldn't see this either locally nor in a
proper imap view (`mbsync -ls` will show you what folders it deems
existent).

near side box '&AOE' cannot be opened

[Tamás G. <ta...@gu...>]

.mbsyncrc:
> FSync no
> 
> IMAPAccount t.gulacsi
> Host localhost
> Port 1143
> User "t.g...@un...,fc...19"
> Pass ""
> AuthMechs LOGIN
> SSLType None
> 
> IMAPStore t.gulacsi-remote
> Account t.gulacsi
> 
> MaildirStore t.gulacsi-local
> Path ~/mail/t.gulacsi
> Inbox ~/mail/t.gulacsi/Inbox
> SubFolders Verbatim
> AltMap yes
> 
> Channel t.gulacsi
> Far  :t.gulacsi-remote:
> Near :t.gulacsi-local:
> Create Near
> Patterns *
> Patterns "!Trash !Conversation !Deleted !Drafts !Junk !Outbox !RSS !Scheduled"
> Patterns "!\"Conversation History\" !\"Deleted Items\""
> Patterns "!\"Junk Email\""
> Patterns "!\"RSS Feeds\""
> Sync Pull
> SyncState *


$ mbsync -V t.gulacsi
Reading configuration file /home/tgulacsi/.mbsyncrc
C: 0/1  B: 0/0  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
Channel t.gulacsi
Opening far side store t.gulacsi-remote...
Resolving localhost... ok
Connecting to localhost ([::1]:1143)...
Opening near side store t.gulacsi-local...
Logging in...
*** IMAP Warning *** Password is being sent in the clear
C: 0/1  B: 0/40  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
Opening far side box INBOX...
Opening near side box INBOX...
Loading far side box...
Loading near side box...
near side: 153 messages, 0 recent
far side: 599 messages, 0 recent
Synchronizing...
C: 0/1  B: 1/40  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
Opening far side box INBOX/Mag&AOE-n/BOKCs...
Opening near side box INBOX/Mag&AOE-n/BOKCs...
Error: channel t.gulacsi: near side box INBOX/Mag&AOE-n/BOKCs cannot be opened.


BUT!

$ mbsync -V 't.gulacsi:INBOX/Mag&AOE-n/BOKCs'
Reading configuration file /home/tgulacsi/.mbsyncrc
C: 0/1  B: 0/1  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
Channel t.gulacsi
Opening far side store t.gulacsi-remote...
Resolving localhost... ok
Connecting to localhost ([::1]:1143)...
Opening near side store t.gulacsi-local...
Logging in...
*** IMAP Warning *** Password is being sent in the clear
Opening far side box INBOX/Mag&AOE-n/BOKCs...
Opening near side box INBOX/Mag&AOE-n/BOKCs...
Loading far side box...
Loading near side box...
near side: 91 messages, 0 recent
far side: 149 messages, 0 recent
Synchronizing...
C: 1/1  B: 1/1  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0


AND!

$ mbsync -V 't.gulacsi:INBOX/Magán/BOKCs'
Reading configuration file /home/tgulacsi/.mbsyncrc
C: 0/1  B: 0/1  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
Channel t.gulacsi
Opening far side store t.gulacsi-remote...
Resolving localhost... ok
Connecting to localhost ([::1]:1143)...
Opening near side store t.gulacsi-local...
Logging in...
*** IMAP Warning *** Password is being sent in the clear
Opening far side box INBOX/Magán/BOKCs...
Opening near side box INBOX/Magán/BOKCs...
Creating near side box INBOX/Magán/BOKCs...
Maildir notice: no UIDVALIDITY, creating new.
Loading far side box...
Loading near side box...
near side: 0 messages, 0 recent
far side: 149 messages, 0 recent
Synchronizing...
C: 1/1  B: 1/1  F: +0/0 *0/0 #0/0  N: +91/91 *0/0 #0/0

Works.
Another strange thing is that both SELECTs "INBOX/Mag&AOE-n/BOKCs" on the server side
(which is a self-written MS Graph-IMAP proxy).

What I've configure wrong?

Thanks,
Tamás Gulácsi

Re: Synchronize fails after upgrading to 1.5

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

On Fri, Sep 13, 2024 at 07:00:02AM +0000, jordan--- via isync-devel wrote:
>I found a report on Reddit that looks like a similar problem, but with
>no resolution:
>https://www.reddit.com/r/commandline/comments/1d9ik8a/mbsync_not_downloading_all_messages/
>
>Do you have any suggestions on what I might need to fix?
>
yes, this is a common theme; you'll find lots of related threads in the
list archive.
i now also answered on reddit.

in your case the interesting question is whether the buggy run occurred
before or after you upgraded to 1.5 (the upgrade wouldn't resolve the
situation once it manifests).

Synchronize fails after upgrading to 1.5

[<jo...@jn...>]

Hello,

I have a strange behavior when attempting to sync in the last few days, and I suspect it's related to recently upgrading isync from 1.4.4 to 1.5. Specifically, `mbsync -V` shows something like this:

...
Opening far side box INBOX...
Opening near side box INBOX...
Loading far side box...                                        
Loading near side box...
near side: 799 messages, 734 recent
far side: 888 messages, 0 recent
Synchronizing...
...

So it sees messages available on the server, but 1. none of them are marked "recent", which is surprising to me, and 2. it doesn't actually spend any time synchronizing, and it doesn't actually synchronize any messages (it immediately moves onto the next folder).

I doubt it's a server issue, as the same config (ignoring SSLType vs TLSType) currently works on a different computer still on 1.4.4.

I found a report on Reddit that looks like a similar problem, but with no resolution: https://www.reddit.com/r/commandline/comments/1d9ik8a/mbsync_not_downloading_all_messages/

Do you have any suggestions on what I might need to fix?

Thank you!

--
Jordan

Re: how to debug or ignore "BODY is no literal" error

[Alan S. <ala...@po...>]

Hello,

On 2024-08-29 16:39, Oswald Buddenhagen via isync-devel <isy...@li...> writes:

> On Thu, Aug 29, 2024 at 03:57:39PM +0200, Alan Schmitt wrote:
>>F: >>> 7 UID FETCH 1949470 (BODY.PEEK[])
>>F: * 14550 FETCH (UID 1949470 BODY[] "")
>>IMAP error: malformed FETCH response from ********: BODY is no literal
>>
>>Is there a way to ignore the problematic message and synchronize the
>>other ones?
>>
> no, but you can try locating it using an interactive imap browser, like
> thunderbird (enable the "arrival order" (or similar) column, which
> really shows the uids).
>
> the message in question seems to have zero bytes. if the server is using
> maildir, this might be the result of a badly handled crash. if you have
> file system access to it, you can trivially locate and prune the file.

Thank you for the suggestions.

This Schrödinger message kept disappearing and coming back (now it’s
gone for good). I managed to connect to the imap server directly when it
was there, and I observed that it was completely empty, that I could not
set flags on it (I tried to set the Deleted flag), and that expunging
would make it go away (temporarily).

I also played with some email clients to identify the message, and it
seems it was a leftover from a calendar invitation.

In any case all seems well now.

Best,

Alan

Re: how to debug or ignore "BODY is no literal" error

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

On Thu, Aug 29, 2024 at 03:57:39PM +0200, Alan Schmitt wrote:
>F: >>> 7 UID FETCH 1949470 (BODY.PEEK[])
>F: * 14550 FETCH (UID 1949470 BODY[] "")
>IMAP error: malformed FETCH response from ********: BODY is no literal
>
>Is there a way to ignore the problematic message and synchronize the
>other ones?
>
no, but you can try locating it using an interactive imap browser, like
thunderbird (enable the "arrival order" (or similar) column, which
really shows the uids).

the message in question seems to have zero bytes. if the server is using
maildir, this might be the result of a badly handled crash. if you have
file system access to it, you can trivially locate and prune the file.

how to debug or ignore "BODY is no literal" error

[Alan S. <ala...@po...>]

Hello,

I no longer can sync one of the imap servers I use because I get an
error "BODY is no literal". As no mail is synchronized, I don’t know how
to delete the problematic email as I don’t know which one it is…

Here is what debug says:

synchronizing new messages on far side
unpropagated old message 1949470
unpropagated old message 1949476
unpropagated old message 1949484
unpropagated old message 1949488
unpropagated old message 1949492
synchronizing flags
propagating new messages
N: Called get_uidnext, ret=35763
-> log: F 1 35763 (save UIDNEXT of near side)
-> log: # 1949470 0 rLci37YnnlGz (new TUID)
-> log: # 1949476 0 ysI7YBE7WLgO (new TUID)
-> log: # 1949484 0 lnyasNRsH59r (new TUID)
-> log: # 1949488 0 PWmLcivibHT/ (new TUID)
-> log: # 1949492 0 yP75WP1GQVJf (new TUID)
N: Called get_memory_usage, ret=0
F: [ 9] Enter fetch_msg, uid=1949470, want_flags=no, want_date=no
F: >>> 7 UID FETCH 1949470 (BODY.PEEK[])
F: [ 9] Leave fetch_msg
N: Called get_memory_usage, ret=0
F: [ 10] Enter fetch_msg, uid=1949476, want_flags=no, want_date=no
(1 in progress) F: >>> 8 UID FETCH 1949476 (BODY.PEEK[])
F: [ 10] Leave fetch_msg
N: Called get_memory_usage, ret=0
F: [ 11] Enter fetch_msg, uid=1949484, want_flags=no, want_date=no
(2 in progress) F: >>> 9 UID FETCH 1949484 (BODY.PEEK[])
F: [ 11] Leave fetch_msg
N: Called get_memory_usage, ret=0
F: [ 12] Enter fetch_msg, uid=1949488, want_flags=no, want_date=no
(3 in progress) F: >>> 10 UID FETCH 1949488 (BODY.PEEK[])
F: [ 12] Leave fetch_msg
N: Called get_memory_usage, ret=0
F: [ 13] Enter fetch_msg, uid=1949492, want_flags=no, want_date=no
(4 in progress) F: >>> 11 UID FETCH 1949492 (BODY.PEEK[])
F: [ 13] Leave fetch_msg
F: [ 7] Callback leave load_box
F: * 14550 FETCH (UID 1949470 BODY[] "")
IMAP error: malformed FETCH response from ********: BODY is no literal
F: Callback enter bad store
F: Enter cancel_store
F: [ 9] Callback enter fetch_msg, sts=4
F: [ 9] Callback leave fetch_msg
F: [ 10] Callback enter fetch_msg, sts=4
F: [ 10] Callback leave fetch_msg
F: [ 11] Callback enter fetch_msg, sts=4
F: [ 11] Callback leave fetch_msg
F: [ 12] Callback enter fetch_msg, sts=4
F: [ 12] Callback leave fetch_msg
F: [ 13] Callback enter fetch_msg, sts=4
F: [ 13] Callback leave fetch_msg
F: Leave cancel_store
N: [ 14] Enter cancel_cmds
N: [ 14] Callback enter cancel_cmds
N: Enter free_store
N: Leave free_store
N: [ 14] Callback leave cancel_cmds
N: [ 14] Leave cancel_cmds
F: Callback leave bad store
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).


Is there a way to ignore the problematic message and synchronize the
other ones?

Thanks,

Alan

Re: packet length too long with tunnel

[Alan S. <ala...@po...>]

On 2024-08-28 11:56, Evgeniy Berdnikov <bi...@pr...> writes:

> On Wed, Aug 28, 2024 at 10:40:30AM +0200, Alan Schmitt wrote:
>> I still have an error at the end of synchronization, but it does not
>> prevent me from doing the sync.
>> 
>> C: 2/3  B: 18/19  F: +0/1 *1/1 #0/0 -0/0  N: +4/4 *0/0 #0/0 -0/080F2FCE57C7F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:689:
>
>  This is because server imap.zaclys.net on client's LOGOUT drops down TCP
>  connection without proper SSL termination. It's a violation of SSL protocol,
>  but many modern servers have such behaviour.
>
>  Probably redirection of stderr in tunnel command such as "... 2>/dev/null"
>  helps to suppress this output.

It works, thanks!

Alan

Re: packet length too long with tunnel

[Evgeniy B. <bi...@pr...>]

On Wed, Aug 28, 2024 at 10:40:30AM +0200, Alan Schmitt wrote:
> I still have an error at the end of synchronization, but it does not
> prevent me from doing the sync.
> 
> C: 2/3  B: 18/19  F: +0/1 *1/1 #0/0 -0/0  N: +4/4 *0/0 #0/0 -0/080F2FCE57C7F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:689:

 This is because server imap.zaclys.net on client's LOGOUT drops down TCP
 connection without proper SSL termination. It's a violation of SSL protocol,
 but many modern servers have such behaviour.

 Probably redirection of stderr in tunnel command such as "... 2>/dev/null"
 helps to suppress this output.
-- 
 Eugene Berdnikov

Re: packet length too long with tunnel

[Alan S. <ala...@po...>]

On 2024-08-28 11:07, Evgeniy Berdnikov <bi...@pr...> writes:

>  Is SSLType is set to "None" in your config? I suspect in your configuration
>  output from tunnel is tried to be interpreted as SSL, but it is plain IMAP.

That was it, thanks!

I still have an error at the end of synchronization, but it does not
prevent me from doing the sync.

C: 2/3  B: 18/19  F: +0/1 *1/1 #0/0 -0/0  N: +4/4 *0/0 #0/0 -0/080F2FCE57C7F0000:error:0A000126:SSL routines::unexpected eof while reading:ssl/record/rec_layer_s3.c:689:

Thanks again,

Alan