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

Re: Working with gmail

[Robin L. P. <rlp...@di...>]

On Thu, Nov 06, 2025 at 02:43:55AM +0200, Gesh wrote:
> Hi,
> I'm struggling a bit to set mbsync up to sync some gmail accounts.
> I wanted to pull out the inbox, outbox and draft folders to be synced more
> frequently, but mbsync complains that eg
> > Error: channel gesh-iobox: near side box [Gmail]/Sent Mail cannot be opened.
> Investigating suggests I need to escape the name of the near-side box by writing
> it as
> > Channel gesh-iobox-sent
> > Far :gesh-remote:"[Gmail]/Sent Mail"
> > Near :gesh-local:"\\[Gmail\\]/Sent Mail"
> >
> > Channel gesh-iobox-drafts
> > ...
> or
> > Channel gesh-iobox
> > Far :gesh-remote:
> > Near :gesh-local:
> > Patterns INBOX "\\[Gmail\\]/Sent Mail" "\\[Gmail\\]/Drafts"
> which works, but is ugly and does not match the suggestions I see elsewhere
> online. This raises
> Q1: Is there a nicer way of writing this?

PFA my entire mbsyncrc (except the parts that say "[SNIP]"), which
works perfectly for me.  There is a Patterns section that should
show how to do what you want.  You seem to have double backslashes.

I run it with `mbsync gmail-quick` and less often with `mbsync gmail`.

> A tangential bug I had here is that for some reason, syncing messages meant that
> a bunch of them had their delivery times reset *on the server end*, so that when
> my phone went to check for email, it moved my huge backlog to the end of history
> where I was forced to handle it. I've set
> > CopyArrivalDate yes
> and hope it fixes things -- I've deleted the old messages, so I probably will
> only be able to report negative results here.
> Q2: Has anyone else encountered this?

Not me.

> Finally, the mismatch between the local maildirs (using folders and notmuch
> tags) and the remote situation (using labels) is making me a little twitchy.
> For one, this means I'm duplicating syncs (though I tend not to multilabel, so
> this is less bad than it seems). For another, this means my notmuch tags are
> limited to my computer, and won't eg sync to my phone.
> The canonical solution for this appears to be to use programs like lieer[2] to
> use Google's APIs directly, but those tend to be overspecialized and
> overwrought.
> An alternative concept would be to patch mbsync so it stores/updates IMAP
> extension attributes. Eg for Gmail[1], a configuration such as
> > IMAPAccount ...
> > StoreAttr X-GM-MSGID X-GM-THRID X-GM-LABELS
> > UpdateAttr X-GM-LABELS
> would have the effect of adding those three headers to the messages it syncs --
> populated with the results of
> > aa FETCH $UID (X-GM-MSGID X-GM-THRID X-GM-LABELS)
> and when syncing the message back to the server, emitting
> > aa STORE $UID X-GM-LABELS ($X-GM-LABELS)
> with the value taken from the header and these custom headers stripped.
> One could then use notmuch to convert from known labels in X-GM-LABELS to
> notmuch-internal labels, and have one's MUA edit the X-GM-LABELS header upon
> retagging. But then, this already seems overwrought, so I'm not sure how much
> value it has.
> Given the above, it might be worth considering the notmuch labels as local
> conveniences to be used when reading mail most comfortably at my computer,
> ignore Gmail's ability to multi-label emails and use the folders to classify
> emails for my other devices (eg phones)
> Q3: How do you guys' Gmail and notmuch labels interact? How much effort do you
> put into making them sync up? What do you do about the duplicate entries?

Never heard of notmuch before, sorry; I use mutt with mine and I
don't label.

> Finally finally, I'm not sure I 100% understand the guidance re
> trashing/expunging and its interaction with Gmail -- do I understand correctly
> that the default behaviour is for the Gmail server to automatically delete email
> once it's vanished from all labels, preventing batch processing, and that the
> recommended behavior instead is to set it to move messages to Trash once their
> final copy is expunged?

I did what https://sourceforge.net/p/isync/mailman/message/36386997/
says and it works for me.  :shrug:

Re: Working with gmail

[Marton B. <ba...@gm...>]

Hi,

I use Patterns in .mbsynrc and there I can have things like
"[Gmail]/Spam"
with no problems. E.g.,

Channel home-updown
Far :home-remote:
Near :home-local:
Patterns "INBOX" "[Gmail]/Spam" "[Gmail]/Trash" "[Gmail]/Drafts" "2read"
Expunge Both

Channel home-up
Far :home-remote:
Near :home-local:
Patterns * ![Gmail]* !INBOX !2read
Create Far
Sync Push
Expunge Far


(And locally, I flatten paths:
Flatten .
)

As for trash, try this link:
https://mail.google.com/mail/u/0/#search/has%3Anouserlabels+-in%3ASent+-in%3AChat+-in%3ADraft+-in%3AInbox
(equivalent to search query
has:nouserlabels -in:Sent -in:Chat -in:Draft -in:Inbox
i.e., mails without labels other than in Sent, Chat, Draft, Inbox). Whenever I delete something locally without moving it in trash, the email ends up here. I did that for years without ever seeing the above unlabeled lot so now each evening a script launches the above url for me and I delete 100, decade-old mails via the web interface. I haven't come up with a better way, but also it's only two clicks and it's fun to see what I was doing in 2013 ;-).

Other than this, I pretend that Google works with actual folders so I let mbsync mimic the label structures as my local maildir folders. I only save each mail into one folder so don't get duplicates. I only use notmuch for indexing to provide search when needed, not for labels. Trying to KISS.

Hope this is somewhat helpful, best wishes,
Marton

On Wed, Nov 26, 2025 at 02:27:59PM +0200, Gesh wrote:
> 26.11.2025 12:50:02 Oswald Buddenhagen <osw...@gm...>:
> 
> > On Thu, Nov 06, 2025 at 02:43:55AM +0200, Gesh wrote:
> >>> Error: channel gesh-iobox: near side box [Gmail]/Sent Mail cannot be
> opened.
> >> Investigating suggests I need to escape the name of the near-side box by
> writing
> >> it as
> >>> Channel gesh-iobox-sent
> >>> Far :gesh-remote:"[Gmail]/Sent Mail"
> >>> Near :gesh-local:"\\[Gmail\\]/Sent Mail"
> >>>
> > huh ... where did you get that from?
> 
> Experimenting with various syntaxes, this was the only one that didn't throw
> errors - unclear why, though.
> 
> >> A tangential bug I had here is that for some reason, syncing messages meant
> that a bunch of them had their delivery times reset *on the server end*,
> >>
> > i suppose this would happen if the messages are moved between boxes
> client-side (and thus re-delivered to gmail's unified inbox).
> 
> It's been a while, I've forgotten if this was also in my standard addresses,
> but I made the mistake of trying to use this to mirror emails to a backup
> account which was already getting emails by bouncing them. I'm unsure if that
> was well-advised.
> 
> >> An alternative concept would be to patch mbsync so it stores/updates IMAP
> extension attributes. Eg for Gmail[1], a configuration such as
> >>> IMAPAccount ...
> >>> StoreAttr X-GM-MSGID X-GM-THRID X-GM-LABELS
> >>> UpdateAttr X-GM-LABELS
> >>
> > i think it's a bit "optimistic" that one could just name random attributes
> and expect them to be handled usefully without isync knowing their semantics.
> > anyway, there is a long-standing todo item to support imap keywords.
> 
> OK, so how do you approach the situation that
> - gmail duplicates emails across folders to simulate multi-labeling
> - in particular, it has a catchall folder containing all mail
> - I use both a phone and a computer, so any relabelling needs to be propagated
> back serverside so the phone picks it up
> 
> I _guess_ I could configure notmuch to ignore the all-mail folder for
> day-to-day, then double check from time to time that I'm not losing any mail
> there, and otherwise just use folders as folders?
> 
> >> Finally finally, I'm not sure I 100% understand the guidance re trashing/
> expunging and its interaction with Gmail --
> >
> >> do I understand correctly that the default behaviour is for the Gmail server
> to automatically delete email once it's vanished from all labels,
> >>
> > dunno. i don't actively use gmail, and haven't looked at the settings for a
> few years.
> >
> >> preventing batch processing,
> >>
> > no idea what you mean here.
> >
> >> and that the recommended behavior instead is to set it to move messages to
> Trash once their final copy is expunged?
> >>
> > gmail may have a setting to trash on expunge. using that would be a good
> choice, indeed.
> 
> I'm asking for clarification as to the first paragraph of the recommendations -
> not clear on what the default is and what should be changed.
> 
> Thanks!
> Gesh


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

Re: Working with gmail

[Gesh <ge...@ge...>]

26.11.2025 12:50:02 Oswald Buddenhagen <osw...@gm...>:

> On Thu, Nov 06, 2025 at 02:43:55AM +0200, Gesh wrote:
>>> Error: channel gesh-iobox: near side box [Gmail]/Sent Mail cannot be opened.
>> Investigating suggests I need to escape the name of the near-side box by writing
>> it as
>>> Channel gesh-iobox-sent
>>> Far :gesh-remote:"[Gmail]/Sent Mail"
>>> Near :gesh-local:"\\[Gmail\\]/Sent Mail"
>>>
> huh ... where did you get that from?

Experimenting with various syntaxes, this was the only one that didn't throw errors - unclear why, though.

>> A tangential bug I had here is that for some reason, syncing messages meant that a bunch of them had their delivery times reset *on the server end*,
>>
> i suppose this would happen if the messages are moved between boxes client-side (and thus re-delivered to gmail's unified inbox).

It's been a while, I've forgotten if this was also in my standard addresses, but I made the mistake of trying to use this to mirror emails to a backup account which was already getting emails by bouncing them. I'm unsure if that was well-advised.

>> An alternative concept would be to patch mbsync so it stores/updates IMAP extension attributes. Eg for Gmail[1], a configuration such as
>>> IMAPAccount ...
>>> StoreAttr X-GM-MSGID X-GM-THRID X-GM-LABELS
>>> UpdateAttr X-GM-LABELS
>>
> i think it's a bit "optimistic" that one could just name random attributes and expect them to be handled usefully without isync knowing their semantics.
> anyway, there is a long-standing todo item to support imap keywords.

OK, so how do you approach the situation that
- gmail duplicates emails across folders to simulate multi-labeling
- in particular, it has a catchall folder containing all mail
- I use both a phone and a computer, so any relabelling needs to be propagated back serverside so the phone picks it up

I _guess_ I could configure notmuch to ignore the all-mail folder for day-to-day, then double check from time to time that I'm not losing any mail there, and otherwise just use folders as folders?

>> Finally finally, I'm not sure I 100% understand the guidance re trashing/expunging and its interaction with Gmail --
>
>> do I understand correctly that the default behaviour is for the Gmail server to automatically delete email once it's vanished from all labels,
>>
> dunno. i don't actively use gmail, and haven't looked at the settings for a few years.
>
>> preventing batch processing,
>>
> no idea what you mean here.
>
>> and that the recommended behavior instead is to set it to move messages to Trash once their final copy is expunged?
>>
> gmail may have a setting to trash on expunge. using that would be a good choice, indeed.

I'm asking for clarification as to the first paragraph of the recommendations - not clear on what the default is and what should be changed.

Thanks!
Gesh

Re: Scripting Problem

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

On Mon, Nov 24, 2025 at 01:25:25PM +0100, Ulrich Wisser via isync-devel wrote:
>I do get a return value of 1 all the time. The only error I can see in 
>the logs is, isync tries to access  /root/Maildir/.mbsyncstate although 
>it runs as user abc.
>
>Any ideas or hints are welcome! What am I doing wrong?
>
it seems plausible that cron doesn't set up $HOME correctly when 
changing the user.

>My configuration looks like
>
>    SyncState /mail/.mbsync/
>
not being localized to any user, that isn't a very sensible setting. but 
you're overriding it below anyway.

>    IMAPAccount ulrich
>    Host mail.xxxx.xx
>    User ul...@xx...
>    Pass xxxxxxxxxx
>    AuthMechs LOGIN
>    SSLType IMAPS
>    PipelineDepth 50
>
>    IMAPStore ulrich_mox
>    Account ulrich
>
>    MaildirStore ulrich_local
>    Path /mail/ulrich/

>    #Inbox /mail/ulrich/Inbox/
>
that one should have no trailing slash.
the fact that it's commented out is likely the reason why the incorrect 
$HOME is being referenced.

>    SubFolders Verbatim
>
>    Channel mox
>    Master :ulrich_mox:
>    Slave :ulrich_local:
>    Patterns *
>    Create Slave
>    Remove Slave
>    Expunge Slave
>    SyncState *
>    Sync Pull
>
>

Re: Working with gmail

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

On Thu, Nov 06, 2025 at 02:43:55AM +0200, Gesh wrote:
>> Error: channel gesh-iobox: near side box [Gmail]/Sent Mail cannot be 
>> opened.
>Investigating suggests I need to escape the name of the near-side box by writing
>it as
>> Channel gesh-iobox-sent
>> Far :gesh-remote:"[Gmail]/Sent Mail"
>> Near :gesh-local:"\\[Gmail\\]/Sent Mail"
>>
huh ... where did you get that from?

>A tangential bug I had here is that for some reason, syncing messages 
>meant that a bunch of them had their delivery times reset *on the 
>server end*,
>
i suppose this would happen if the messages are moved between boxes 
client-side (and thus re-delivered to gmail's unified inbox).

>> CopyArrivalDate yes
>and hope it fixes things
>
i guess it might.

>An alternative concept would be to patch mbsync so it stores/updates 
>IMAP extension attributes. Eg for Gmail[1], a configuration such as
>> IMAPAccount ...
>> StoreAttr X-GM-MSGID X-GM-THRID X-GM-LABELS
>> UpdateAttr X-GM-LABELS
>
i think it's a bit "optimistic" that one could just name random 
attributes and expect them to be handled usefully without isync knowing 
their semantics.
anyway, there is a long-standing todo item to support imap keywords.

>Finally finally, I'm not sure I 100% understand the guidance re 
>trashing/expunging and its interaction with Gmail --

>do I understand correctly that the default behaviour is for the Gmail 
>server to automatically delete email once it's vanished from all 
>labels,
>
dunno. i don't actively use gmail, and haven't looked at the settings 
for a few years.

>preventing batch processing,
>
no idea what you mean here.

>and that the recommended behavior instead is to set it to move messages 
>to Trash once their final copy is expunged?
>
gmail may have a setting to trash on expunge. using that would be a good 
choice, indeed.

ps: i overlooked your message in the moderation queue. it's best to 
subscribe ...

Re: Maildir always in $HOME

[<cos...@du...>]

Thank you!

That did the trick.

/Ulrich


Am 25.11.25 um 15:39 schrieb Britt Anderson:
> I have something like this:
>
> MaildirStore my-local
> Subfolders Verbatim
> Path ~/.local/share/mail/
> Inbox ~/.local/share/mail/Inbox
>
> Maybe you need to specify the Inbox?
>
>
>
> cost-cone-elves--- via isync-devel <isy...@li...>
> writes:
>
>> Hi,
>>
>> I try to set a different store for my near side.
>>
>>   MaildirStore ulrich_local
>>   Path /mail/ulrich/
>>   SubFolders Verbatim
>>
>> But I always do get some files in ~/Maildir
>>
>> I tried debugging and strace but all I can see is that get_box_path always returns ~/Maildir.
>>
>>   N: Leave select_box, ret=0
>>   N: Called get_box_path, ret=/home/abc/Maildir
>>
>> What am I doing wrong?
>>
>> Kind regards from Stockholm
>>
>> /Ulrich
>>
>> _______________________________________________
>> isync-devel mailing list
>> isy...@li...
>> https://lists.sourceforge.net/lists/listinfo/isync-devel
>>
>

Re: Maildir always in $HOME

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

I have something like this:

MaildirStore my-local
Subfolders Verbatim
Path ~/.local/share/mail/
Inbox ~/.local/share/mail/Inbox

Maybe you need to specify the Inbox?



cost-cone-elves--- via isync-devel <isy...@li...>
writes:

> Hi,
>
> I try to set a different store for my near side.
>
>  MaildirStore ulrich_local 
>  Path /mail/ulrich/ 
>  SubFolders Verbatim
>
> But I always do get some files in ~/Maildir 
>
> I tried debugging and strace but all I can see is that get_box_path always returns ~/Maildir. 
>
>  N: Leave select_box, ret=0
>  N: Called get_box_path, ret=/home/abc/Maildir
>
> What am I doing wrong?
>
> Kind regards from Stockholm
>
> /Ulrich
>
> _______________________________________________
> isync-devel mailing list
> isy...@li...
> https://lists.sourceforge.net/lists/listinfo/isync-devel
>


-- 
Britt Anderson, PhD & MD
Dept. of Psychology and Centre for Theoretical Neuroscience
University of Waterloo, Canada
https://brittlab.uwaterloo.ca

Maildir always in $HOME

[<cos...@du...>]

Hi,

I try to set a different store for my near side.

    MaildirStore ulrich_local
    Path /mail/ulrich/
    SubFolders Verbatim

But I always do get some files in ~/Maildir

I tried debugging and strace but all I can see is that get_box_path 
always returns ~/Maildir.

    N: Leave select_box, ret=0
    N: Called get_box_path, ret=/home/abc/Maildir

What am I doing wrong?


Kind regards from Stockholm

/Ulrich

Scripting Problem

[Ulrich W. <ul...@wi...>]

Hi,

I use isync (version 1.4.4) to backup my email to my local NAS. It runs 
in a docker container every five minutes.

I try to determine if the sync was successful by looking at the return 
value. Unfortunately I do get a return value of 1 all the time. The only 
error I can see in the logs is, isync tries to access  
/root/Maildir/.mbsyncstate although it runs as user abc.

Any ideas or hints are welcome! What am I doing wrong?

Greetings from rainy Stockholm

/Ulrich


Cron script

    mbsync -V -a -c /config/mbsync.rc
    RC=$?
    echo "INFO: Completed sync.sh Result $RC"


I can only see one error message and that is about the sync state

    Channel mox
    Opening far side store ulrich_mox...
    Resolving mail.xxxx.xx... ok
    Connecting to mail.xxxx.xx (256.256.256.256:993)...
    Opening near side store ulrich_local...
    Connection is now encrypted
    Logging in...
    C: 0/1  B: 0/22  F: +0/0 *0/0 #0/0  N: +0/0 *0/0 #0/0
    Error: cannot read sync state /root/Maildir/.mbsyncstate: Permission
    denied

My configuration looks like

    SyncState /mail/.mbsync/

    IMAPAccount ulrich
    Host mail.xxxx.xx
    User ul...@xx...
    Pass xxxxxxxxxx
    AuthMechs LOGIN
    SSLType IMAPS
    PipelineDepth 50

    IMAPStore ulrich_mox
    Account ulrich

    MaildirStore ulrich_local
    Path /mail/ulrich/
    #Inbox /mail/ulrich/Inbox/
    SubFolders Verbatim

    Channel mox
    Master :ulrich_mox:
    Slave :ulrich_local:
    Patterns *
    Create Slave
    Remove Slave
    Expunge Slave
    SyncState *
    Sync Pull

Re: IMAP pull-and-delete operation

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

On Sun, Nov 16, 2025 at 07:12:20PM +0000, synflower--- via isync-devel wrote:
> Is the MaxMessages code so buggy or poorly tested
> that it's necessary, though?

 When you're going to use a tool which is not designed for your task,
 you take on a role of tester.
-- 
 Eugene Berdnikov

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Mon, Nov 10, 2025 at 12:33:32PM +0100, Philippe Bruhat (BooK) wrote:
>> isync's purpose is to keep both sides in sync. MaxMessages is a deviation
>> from that. when you push that number down to zero, that's _literally_
>> extreme, and you've gone from syncing to fetching.
>
>Can't the requested workflow be simply scripted as:
>- synchronize with isync (getting all the emails from the remote)
>- move all the email to a non-synchronized folder (emptying the local)
>- synchronize again (removing all emails from the remote)

...yes, I suppose so. Is the MaxMessages code so buggy or poorly tested
that it's necessary, though? 

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Mon, Nov 10, 2025 at 10:05:09AM +0100, Oswald Buddenhagen via isync-devel wrote:
>>What is so extreme about what I am doing?
>>
>isync's purpose is to keep both sides in sync. MaxMessages is a 
>deviation from that. when you push that number down to zero, that's 
>_literally_ extreme, and you've gone from syncing to fetching.

Well, yes. But I meant more in the programming sense. Why would reducing
MaxMessages result in a higher likelyhood of something going wrong, and
e.g messages being lost?

>because MaxMessage doesn't really fit the basic scheme, its 
>implementation actually comes at a rather significant cost in 
>complexity; it's easily the most difficult part of the whole codebase.
>i don't know if it would be difficult to make it support zero; it 
>might just work with a few minor changes. patches (with autotests) 
>welcome.

I wee. I will take a look. But be careful what you wish for: the last
time I wrote C code was right after reading K&R... and just before the
Yahoo IPO.

Re: Evade forced external mail archive. Was: Sync IMAP Mailboxes/Folders via ssh?

[Rene K. <ma...@rk...>]

On Fri, Nov 14, 2025 at 06:20:52AM +0100, Peter P. wrote:
> Hi list,
> 
> reviving an older thread here, I am still looking for a solution to the
> problem of my employer wanting to move all email in my account older than X
> years from all folders and host it on a separate webservice[1], thus
> making it inaccessible to me from isync/mutt/notmuch etc.
> The employer is trying to save storage and server ressources this way
> and this questionable move is unavoidable for me.
> 
> Denial Tamling has suggested using tools from the mblaze package to filter
> mail older than a certain date, with Oswald pointing out a pitfall when
> moving these messages, which I don't yet understand:
> 
> * Oswald Buddenhagen via isync-devel <isy...@li...> [2025-07-18 09:02]:
> > On Thu, Jul 17, 2025 at 10:33:36PM +0200, Daniel Tameling wrote:
> > >  mv $(mlist ./INBOX | mpick -t 'from =~ "@github"') ./github/cur
> > > 
> > this will preserve the ,U=nnn infixes of the files, which is a very bad
> > idea.
> 
> Is there a correct way to move all mail from all folders older than X to
> some other folder?
> 
> I am wondering if mblaze/mlist is nevertheless the best way I can
> anticipate the forced archival.

I'd guess that using mrefile(1) should do it the correct way.

> If I would manage to hereby extract all old email from all far-side
> folders I would then need to store it to a near-side folder that is not
> synced back to the far side. How could I nevertheless keep that
> near-side folder in sync across multiple computers? 

By using another IMAP server - which is probably against some rules
about corporate stuff.

> Is there any other way to work around this imminent problem?

As long as you are not deleting anything from the archive, as emails are
just text and files, any method to sync text and files should do.

Evade forced external mail archive. Was: Sync IMAP Mailboxes/Folders via ssh?

[Peter P. <pet...@fa...>]

Hi list,

reviving an older thread here, I am still looking for a solution to the
problem of my employer wanting to move all email in my account older than X
years from all folders and host it on a separate webservice[1], thus
making it inaccessible to me from isync/mutt/notmuch etc.
The employer is trying to save storage and server ressources this way
and this questionable move is unavoidable for me.

Denial Tamling has suggested using tools from the mblaze package to filter
mail older than a certain date, with Oswald pointing out a pitfall when
moving these messages, which I don't yet understand:

* Oswald Buddenhagen via isync-devel <isy...@li...> [2025-07-18 09:02]:
> On Thu, Jul 17, 2025 at 10:33:36PM +0200, Daniel Tameling wrote:
> >  mv $(mlist ./INBOX | mpick -t 'from =~ "@github"') ./github/cur
> > 
> this will preserve the ,U=nnn infixes of the files, which is a very bad
> idea.

Is there a correct way to move all mail from all folders older than X to
some other folder?

I am wondering if mblaze/mlist is nevertheless the best way I can
anticipate the forced archival.

If I would manage to hereby extract all old email from all far-side
folders I would then need to store it to a near-side folder that is not
synced back to the far side. How could I nevertheless keep that
near-side folder in sync across multiple computers? 

Is there any other way to work around this imminent problem?

Thank you so much!
best, Peter

[1] https://www.opentext.com/products/retain-unified-archiving

Re: IMAP pull-and-delete operation

[Philippe B. (BooK) <phi...@br...>]

On Mon, Nov 10, 2025 at 10:05:09AM +0100, Oswald Buddenhagen via isync-devel wrote:
> On Mon, Nov 10, 2025 at 08:31:55AM +0000, syn...@da... wrote:
> > On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
> > > shoehorning isync into doing something it was not designed for
> > 
> > What is so extreme about what I am doing?
> > 
> isync's purpose is to keep both sides in sync. MaxMessages is a deviation
> from that. when you push that number down to zero, that's _literally_
> extreme, and you've gone from syncing to fetching.

Can't the requested workflow be simply scripted as:
- synchronize with isync (getting all the emails from the remote)
- move all the email to a non-synchronized folder (emptying the local)
- synchronize again (removing all emails from the remote)

-- 
 Philippe Bruhat (BooK)

 People are all unique- but some are more unique than others.
                                    (Moral from Groo The Wanderer #22 (Epic))

Re: IMAP pull-and-delete operation

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

On Mon, Nov 10, 2025 at 08:31:55AM +0000, syn...@da... wrote:
>On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
>>shoehorning isync into doing something it was not designed for
>
>What is so extreme about what I am doing?
>
isync's purpose is to keep both sides in sync. MaxMessages is a 
deviation from that. when you push that number down to zero, that's 
_literally_ extreme, and you've gone from syncing to fetching.

>Why is this such a difficult task for isync?
>
because MaxMessage doesn't really fit the basic scheme, its 
implementation actually comes at a rather significant cost in 
complexity; it's easily the most difficult part of the whole codebase.
i don't know if it would be difficult to make it support zero; it might 
just work with a few minor changes. patches (with autotests) welcome.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
>shoehorning isync into doing something it was 
>not designed for

What is so extreme about what I am doing? Why is this such a difficult
task for isync?

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Fri, Oct 31, 2025 at 12:15:55PM +0100, Oswald Buddenhagen via isync-devel wrote:
>why are you insisting on shoehorning isync into doing something it was 
>not designed for?

For one, I've been using isync for years and I have a lot of different
systems set up using it. Isync works great and I know my configuration
works. If I have to change over to Fetchmail then that's a massive
headache.

> just use fetchmail, as i suggested in my first response.

Fetchmail is, as far as I can tell, fundamentally different from isync.
I can't just write a script to convert my .mbsyncrc into a .fetchmailrc
and then have it drop mail into the same Maildir.

It looks like I have to set up fetchmail to deliver to procmail for
every account, and then have procmail write out to the Maildir.

What's more, I can't find any documentation for this workflow, just bits
and pieces. That suggests I'm going to run into hidden gotchas and more
headaches.

So if I can stick to isync (fast, functional) instead of building up a
whole new system (hic sunt dracones) that's obviously preferable.

Working with gmail

[Gesh <ge...@ge...>]

Hi,
I'm struggling a bit to set mbsync up to sync some gmail accounts.
I wanted to pull out the inbox, outbox and draft folders to be synced more
frequently, but mbsync complains that eg
> Error: channel gesh-iobox: near side box [Gmail]/Sent Mail cannot be opened.
Investigating suggests I need to escape the name of the near-side box by writing
it as
> Channel gesh-iobox-sent
> Far :gesh-remote:"[Gmail]/Sent Mail"
> Near :gesh-local:"\\[Gmail\\]/Sent Mail"
>
> Channel gesh-iobox-drafts
> ...
or
> Channel gesh-iobox
> Far :gesh-remote:
> Near :gesh-local:
> Patterns INBOX "\\[Gmail\\]/Sent Mail" "\\[Gmail\\]/Drafts"
which works, but is ugly and does not match the suggestions I see elsewhere
online. This raises
Q1: Is there a nicer way of writing this?

A tangential bug I had here is that for some reason, syncing messages meant that
a bunch of them had their delivery times reset *on the server end*, so that when
my phone went to check for email, it moved my huge backlog to the end of history
where I was forced to handle it. I've set
> CopyArrivalDate yes
and hope it fixes things -- I've deleted the old messages, so I probably will
only be able to report negative results here.
Q2: Has anyone else encountered this?

Finally, the mismatch between the local maildirs (using folders and notmuch
tags) and the remote situation (using labels) is making me a little twitchy.
For one, this means I'm duplicating syncs (though I tend not to multilabel, so
this is less bad than it seems). For another, this means my notmuch tags are
limited to my computer, and won't eg sync to my phone.
The canonical solution for this appears to be to use programs like lieer[2] to
use Google's APIs directly, but those tend to be overspecialized and
overwrought.
An alternative concept would be to patch mbsync so it stores/updates IMAP
extension attributes. Eg for Gmail[1], a configuration such as
> IMAPAccount ...
> StoreAttr X-GM-MSGID X-GM-THRID X-GM-LABELS
> UpdateAttr X-GM-LABELS
would have the effect of adding those three headers to the messages it syncs --
populated with the results of
> aa FETCH $UID (X-GM-MSGID X-GM-THRID X-GM-LABELS)
and when syncing the message back to the server, emitting
> aa STORE $UID X-GM-LABELS ($X-GM-LABELS)
with the value taken from the header and these custom headers stripped.
One could then use notmuch to convert from known labels in X-GM-LABELS to
notmuch-internal labels, and have one's MUA edit the X-GM-LABELS header upon
retagging. But then, this already seems overwrought, so I'm not sure how much
value it has.
Given the above, it might be worth considering the notmuch labels as local
conveniences to be used when reading mail most comfortably at my computer,
ignore Gmail's ability to multi-label emails and use the folders to classify
emails for my other devices (eg phones)
Q3: How do you guys' Gmail and notmuch labels interact? How much effort do you
put into making them sync up? What do you do about the duplicate entries?

Finally finally, I'm not sure I 100% understand the guidance re
trashing/expunging and its interaction with Gmail -- do I understand correctly
that the default behaviour is for the Gmail server to automatically delete email
once it's vanished from all labels, preventing batch processing, and that the
recommended behavior instead is to set it to move messages to Trash once their
final copy is expunged?

Thank you,
Gesh

[1]: https://developers.google.com/workspace/gmail/imap/imap-extensions
[2]: https://github.com/gauteh/lieer

Re: IMAP pull-and-delete operation

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

On Fri, Oct 31, 2025 at 10:27:01AM +0000, syn...@da... wrote:
>I tested it and it works. For data protection reasons, it would be very
>useful if it was possible to set
>	MaxMessage 0
>and have this result in zero messages being left on the server.
>
why are you insisting on shoehorning isync into doing something it was 
not designed for? just use fetchmail, as i suggested in my first 
response.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Tue, Oct 07, 2025 at 01:46:42PM +0200, Oswald Buddenhagen via isync-devel wrote:
>On Tue, Oct 07, 2025 at 11:36:56AM +0000, syn...@da... wrote:
>>If I configure
>>	MaxMessages 1
>>	ExpireUnread yes
>>	ExpireSide Far
>>that will result in all emails staying locally archived, but only the
>>most recent message remaining on the server? (excluding flagged
>>messages)
>>
>theoretically yes, though such an extreme value might derail it one 
>way or another (it's certainly not auto-tested). give it shot with a 
>low-value mailbox first.

I tested it and it works. For data protection reasons, it would be very
useful if it was possible to set
	MaxMessage 0
and have this result in zero messages being left on the server.

Currently setting the value to 0 disables MaxMessages. Therefore one
email is always left on the server, even though this email may contain
sensitive or personal information.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

On Tue, Oct 07, 2025 at 01:46:42PM +0200, Oswald Buddenhagen via isync-devel wrote:
>On Tue, Oct 07, 2025 at 11:36:56AM +0000, syn...@da... wrote:
>>If I configure
>>	MaxMessages 1
>>	ExpireUnread yes
>>	ExpireSide Far
>>that will result in all emails staying locally archived, but only the
>>most recent message remaining on the server? (excluding flagged
>>messages)
>>
>theoretically yes, though such an extreme value might derail it one 
>way or another (it's certainly not auto-tested). give it shot with a 
>low-value mailbox first.

Is there a better way to achieve the desired result of "messages
archived locally, no messages left on the server"...?

Re: IMAP pull-and-delete operation

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

On Tue, Oct 07, 2025 at 11:36:56AM +0000, syn...@da... wrote:
>If I configure
>	MaxMessages 1
>	ExpireUnread yes
>	ExpireSide Far
>that will result in all emails staying locally archived, but only the
>most recent message remaining on the server? (excluding flagged
>messages)
>
theoretically yes, though such an extreme value might derail it one way 
or another (it's certainly not auto-tested). give it shot with a 
low-value mailbox first.

Re: IMAP pull-and-delete operation

[<syn...@da...>]

>we have at least one known user who achieves something to that effect 
>by using MaxMessages coupled with "ExpireSide Far".

If I configure
	MaxMessages 1
	ExpireUnread yes
	ExpireSide Far
that will result in all emails staying locally archived, but only the
most recent message remaining on the server? (excluding flagged
messages)


>
>if you want something even more "thorough", you need to use fetchmail 
>instead.
>
>
>_______________________________________________
>isync-devel mailing list
>isy...@li...
>https://lists.sourceforge.net/lists/listinfo/isync-devel

Re: IMAP pull-and-delete operation

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

On Mon, Oct 06, 2025 at 09:43:31PM +0000, synflower--- via isync-devel wrote:
>Therefore I need to find a way to achieve POP3-like pull-and-delete
>functionality on a server that only supports IMAP.
>
we have at least one known user who achieves something to that effect by 
using MaxMessages coupled with "ExpireSide Far".

if you want something even more "thorough", you need to use fetchmail 
instead.