[Users] Deleting messages previously retained on POP server

[Jeremy Nicoll]

On Tue, 2 Apr 2019, at 00:41, Papa Oz. wrote:
> Claws newbie here.  I finally had to give up on Eudora. 
> 
> I prefer POP to IMAP.
> 
> I have several machines.  Each can read the mail.  All are set to leave
> mail on the server.  One is designated to archive all the mail.  On
> that machine I want to selectively mark messages to be deleted from the
> server, but I want to keep them on the client.  

It's been a long time since I did something like this, but when I did it 
was with programmes I wrote myself, which issued a series of POP
commands to the server.  If you're looking for a way for Claws to do it 
for you, I've no idea if that's easy to organise.

My programmes relied on the POP sessions issuing a "UIDL" command at the 
start, which caused the server to return a list of unique ids corresponding
to all the messages stored there at that point.  So you'd see a list like

  1  uid5458475
  2  uid8232323
  3  uid19822222
...

meaning that at that point the mailbox contained messages with those 
specified uids.  Commands issued to the POP server, eg to retrieve (ie
download) a message use the other number, eg 

  RETR 2

fetches the second message, ie the one with uid value: uid8232323

So it's possible for you to maintain your own list of the uid values of the 
messages that you have downloaded, either by writing all the code to do
the downloading of messages, and storing UIDL values, or - if eg Claws 
already issues a UIDL command, by your program reading the Claws log
to find out on each connection what the Claws session actually did.

Later, on a deletions session you again issue UIDL and get eg

  1  uid...
  2  uid...
  3  uid...
  4  uid...
  5  uid19822222
  6  uid5458475
  7  uid... 

You check each entry that's shown there and see that the ones for,
for example, messages 5 and 6 were seen on a download session earlier, 
so they are safe to delete, and you issue

  DELE 5
  DELE 6

and check that the server receives the commands ok, and later ends the
session ok.   (Both are necessary because in POP a DELE command only
asks the server to mark an item for future deletion, and the delete is not
done until the whole session ends cleanly.   That means it's possible to 
'cancel'  such delete requests by failing to end the session cleanly, which
is sometimes useful.    [Years ago, there were some non-RFC-compliant
POP servers around that did not work that way, and immediately deleted
messages when a DELE request was sent.]     


I don't know if that's useful.   You'll find a full description at:

https://tools.ietf.org/html/rfc1939

-- 
Jeremy Nicoll - my opinions are my own.