Re: pop3 leave on server, then fetch, Expire = delete from server

[Peter Davis <pd@world.std.com>]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> * "Peter Davis" <pdavis@pageflexinc.com>  on Tue, 30 Apr 2002
> | I could live with an explicit function that expunges all messages that are
> | marked for expiration.
> 
> POP does not work that way.  The client never expunges messages.  All the
> client does is send DELE msg-id commands where msg-id is the sequential
> number of a message in the drop to mark for deletion.  Deletion does not
> actually occour until the client gracefully closes the connection to the
> server with the QUIT command.  If the server does not receive the QUIT
> command from the client it will automatically invoke RSET and remove all
> DELE marks from the drop.

Let me try this again.  Franklin Lee's epop3mail and pop3.el (in
XEmacs) both have the ability to leave messages on the server.  They
record a listing of message IDs in files (.uidls...something) in order
to know which messages have been downloaded.  As far as I can tell,
the messages themselves also contain the message ID and the
mail-source from which the message came.

Suppose that whenever one of these messages is marked as expirable,
gnus also marks the corresponding message ID in the appropriate .uidls
file.  Then, when I want to expunge, I have a function which reads the
.uidls file, connects with the server and deletes those messages which
have been so marked.  Am I missing something?  This doesn't require
anything other than what POP already does.

In fact, Franklin Lee's package also includes epop3-manage-mailbox,
which can connect to a server, display a list of messages on that
server, and allow users to selectively delete those messages (by
marking them and then typing 'x' to delete all marked messages).  I am
not an e-lisp expert, but it seems to me the pieces are already there,
and someone with more know-how could connect them to make the server
expunging "automatic".


> > If the time the server requires to parse your drop is greater than its
> internal timeout (30 seconds by default on many servers) then you will not
> be able to get your mail.  The server will drop the connection before the
> client can acknowledge the results of the STAT command.  This is why leave
> mail on server is Evil Incarnate.  On top of that, nnpop3 needs to be able
> to handle a server side timeout connection close and client reconnect for
> every message being read, with the caveat that the contents of the drop
> will change between sessions as new mail is delivered to it.

The messages would be marked, and then all deleted at once by some
user-invoked function.

> See, I planned out nnpop3 back in 1995.  I knew exactly how to make it
> work.  And then I realized how rock-stupid it would be to write something
> that I -knew- would cause mail to bounce.  POP is totally inappropriate for
> a backend for these reasons.

Well, I never envisioned it as a back end.  I thought it could just be
a new function that expunges messages which have expired.

-pd


-- 
--------
                             Peter Davis
               Funny stuff at http://www.pfdstudio.com
                 The artwork formerly shown as prints
    List of resources for children's writers and illustrators at:
                  http://www.pfdstudio.com/cwrl.html