isync-devel

IMAP pull-and-delete operation

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

Hi all,
For data protection reasons, I do not want to leave my emails on the
mail server for all eternity.

Normally this would be easily accomplished by using POP3 as the sync
protocol, and instructing my email client to delete the mails after
downloading.

Unfortunately, many email providers have stopped supporting POP3!

Therefore I need to find a way to achieve POP3-like pull-and-delete
functionality on a server that only supports IMAP.

Lookin at the mbsync man page, it seems like I may be able to do this
using some combination of Sync options. But I am not quite sure which
ones to use.

How do I do this?

Thanks!

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.

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

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

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

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

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

[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 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: 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

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

[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