Re: [Evolution] Evolution 1.2.2 - odd behavior with Yahoo POP server

[guenther <guenther rudersport de>]

> Sounds plausible, but I should have mentioned before that this behavior
> did NOT occur with Outlook Express.  So I agree that this is an odd
> "feature" in Yahoo, but there is apparently some way for Outlook to
> avoid it that Evolution does not know about, or that I have not
> configured properly.  I'm still confused?!?

Now I am confused as well. You sure, you aren't april fooling on us? Or
maybe yahoo on you? ;-))

As the fetched messages are moved to a trash folder, there has to be a
DELE command for sure. And POP3 does not offer more fine grained
commands. You can't configure more, you have done all you can.

So the question is, what does OE really do? Are you sure, OE uses POP3
or maybe IMAP or some weired MS protocol to pass along the 'empty trash'
command, what ever it would be?


[5 minutes later]

Just checked RFC 1939 -- there is one possibility left, although
doubtful and you would have to blame yahoo for using crappy servers...

  DELE msg
    The POP3 server marks the message as deleted.  Any future
    reference to the message-number associated with the message
    in a POP3 command generates an error.  The POP3 server does
    not actually delete the message until the POP3 session
    enters the UPDATE state.

  QUIT
    The POP3 server removes all messages marked as deleted
    from the maildrop and replies as to the status of this
    operation.  If there is an error, such as a resource
    shortage, encountered while removing messages, the
    maildrop may result in having some or none of the messages
    marked as deleted be removed.  In no case may the server
    remove any messages not marked as deleted.

That means, if the server isn't able to delete the marked messages, they
will remain on the server -- maybe in that trash folder, if they
implemented the frontend that way...


  The UPDATE State

    When the client issues the QUIT command from the TRANSACTION state,
    the POP3 session enters the UPDATE state.  (Note that if the client
    issues the QUIT command from the AUTHORIZATION state, the POP3
    session terminates but does NOT enter the UPDATE state.)

    If a session terminates for some reason other than a client-issued
    QUIT command, the POP3 session does NOT enter the UPDATE state and
    MUST not remove any messages from the maildrop.

That would mean, the server never gets the QUIT command from the client
and must not delete the messages. However, nothing is said about the
'marked for deletion' state...

Nice server should drop that state and leave the messages, as it does
not know if the client got those messages...

Not-so-nice server could leave the deletion marks -- what would be a
very nasty way of implementing a "trash folder" for POP3... (No, I did
not say that. No, no one heard that. Don't take that as idea... ;-)


A last wild guess: Is the POP3 connection really shut down or is it
still active? Unless you tell Evo to go offline or close.

(I doubt that, but the ximian hackers have to answer this part. Can you
hear me, hackers??)

Still active POP3 connection would mean, the messages are still on the
server, marked for deletion. And a good frontend would show that with a
trash folder...

That would assume, yahoo allows more than one concurrent POP3 sessions
to the same account...


(You can check that easily by closing Evo and looking at the frontend
again.)


That's all I can think of right now. And you are really the first one
coming up with that strange problem...

...guenther


-- 
char *t="\10pse\0r\0dtu\0  ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}