Re: [bug-mailutils] Problem with timeout interaction

[Alain Magloire]

> 
> Hello,
> 
> Alain Magloire <address@hidden> wrote:
> 
> > In any case, I do agree for POP3D if you quit before reaching
> > the update state any messages mark deleted should be unmark
> > and left untouch (except the UID, it is preserve across sessions).
> 
> Agreed.
>  
> > But my question is:
> > In a POP3 session should the deleted messages in the update state(after the 
> > QUIT)
> > be __only the messages marked deleted in *that current pop3 session*__ not
> > messages marked(via Status: d) in an unrelated action on the mailbox ?
> 
> No, I guess not. After a good thought I must admit that my proposition
> about not using attribute_set_deleted() was completely wrong. We *have to*
> use Status flag for keeping the deletion mark. I'll elaborate on this
> below.
>  
> > I think, sergey, you bring a good point, that we probably should
> > not use attribute_set_deleted() to mark message, but rather maintain
> > our own list to not to interfere whith any previous state of the mailbox.
> 
> On the other hand, this seems to bring more questions than answers. Here
> are few of them off the top of my head (there may be more of them...):
> 
> 1) What is the semantics of the deletion mark, then? If we do not use it
> to mark messages for deletion, what purpose does it serve?
> 
> 2) Interoperation issue I (internal): once we modify pop3d to have its
> internal list of deleted messages, we'll have to do the same for the
> rest of utilities, which means moving this "internal list support" to
> the core libmailbox.
> 
> 3) Interoperation issue II (external): most existing MUAs use Status:
> field to keep the deletion information. If we switch to the "internal
> list" method, the compatibility between Mailutils and other MUAs will
> be lost.
> 
> 4) The expunge mechanism discerns messages to be deleted by the presence
> of "D" mark in Status: field. If we switch to another method, this will
> have to be rewritten.
> 
> 5) A message may be marked as deleted *and* still remain in the mailbox.
> It is normal. Whatever method we will be using for marking deleted
> messages, we must provide for storing this information along with the
> message itself for eventual future use (e.g. either unmarking or expunging).
> The only place where such information may be stored is in the header. Thus,
> we'll end up creating new Status field.
> 
> 6) After all, keeping deletion mark in Status is logical and
> complies to RFCs: that's what this header had been created for.
> 
> In short, my opinion is that Status: is the right place for the
> deletion mark.
> 
> 
> Returning to the the pop3d issue. The way Jeff proposed seems
> to be a good solution. The only implication it brings is
> the following: if the mailbox being opened already had some
> messages marked for deletion, they will be unmarked before
> exiting on timeout. I don't know if it is wrong. Possibly
> we should even provide an option that will force pop3d to
> clear any deletion marks from the messages in a mailbox right
> after opening it. This will ensure a proper interoperation with
> the clients like Eudora.
> 
> However, to fix this issue as well I propose the following
> scenario:
> 
> 1) In pop3d.h:
> 
> #define POP3_ATTRIBUTE_DELE 0x0001
> 
> 2) In dele.c:
> 
> int
> pop3d_dele (const char *arg)
> {
>   size_t num;
>   message_t msg;
>   attribute_t attr = NULL;
> 
>   /* ... */
>   /* Everything remains untouched except this line: */
>   attribute_set_userflag (attr, POP3_ATTRIBUTE_DELE);
>   pop3d_outf ("+OK Message %d marked\r\n", num);
>   return OK;
> }
> 
> 3) In extra.c (pop3d_abquit): No changes needed.
> 
> 4) In quit.c
> 
> int
> pop3d_quit (const char *arg)
> {
>   int err = OK;
>   if (strlen (arg) != 0)
>     return ERR_BAD_ARGS;
> 
>   if (state == TRANSACTION)
>     {
>       pop3d_fix_mark (); /* Note this. That's the only change */
>       pop3d_unlock ();
>       if (mailbox_flush (mbox, 1) != 0)
>         err = ERR_FILE;
>     ...
> 
> void
> pop3d_fix_mark ()
> {
>   size_t i;
>   size_t total = 0;
> 
>   mailbox_messages_count (mbox, &total);
> 
>   for (i = 1; i <= total; i++)
>     {
>        message_t msg = NULL;
>        attribute_t attr = NULL;
>        mailbox_get_message (mbox, i, &msg);
>        message_get_attribute (msg, &attr);
>        if (attribute_is_userflag (attr, POP3_ATTRIBUTE_DELE))
>           attribute_set_deleted (attr);
>     }
> }                            
> 
> Advantages:
> 
>  1) No pop3d-inserted deletion marks are preserved when exiting on
>  timeout.
>  2) The deletion marks set via other MUAs are preserved.
>  3) Minimal modifications to the code.
> 

Yes, I like that.
You forgot:
- to change code in retr.c, it should 
not check for attribute_is_deleted.

- also I'm not sure we should set read, attribute_set_read
  when the message is downloaded(via RETR.

I think that POP3 does not need interoperation(external), as
you describe in point (3).  POP3 is far most a dowloading protocol
and interpreting fields like status should be a no-no.

Personnaly, I would remove the header fields:
  Status:
  Content-Length:

They are prone to errors and can confuse MUA.  If 
an MUA need to know if the mail was read/new it should
rely on the UIDL.


> Now, if we provide an option telling pop3d to clear all deletion marks
> at startup, then the administrator of the server is quite free to decide
> whether he needs the marks cleaned up or preserved.
>