[Dovecot] Question about the pop3 feature "leave messages on server for a certain period of time"

Axel Luttgens AxelLuttgens at swing.be
Sat Sep 12 14:07:14 EEST 2009


Le 12 sept. 2009 à 09:27, Charles Marcus a écrit :

> On 9/11/2009, Axel Luttgens (*******) wrote:
>> Well, POP is rather well RFC-based too...  ;-)
>> In fact, POP and IMAP are both well-defined protocols;
>> they just are optimized for each extreme of possible behaviors:
>> remove everything from the server as soon as a local copy has been
>> taken, or leave everything on the server without taking any local
>> copy.
>
> He was talking about the 'leave messages on server' part of POP, which
> you conveniently omitted above.

Hello Charles,

No, I don't think to have omitted anything: I already replied to the  
OP wrt the 'leave messages on server' matter.

Here, I was replying to Leonardo (who's not the OP) who started a new  
idea (a potentially misleading POP vs IMAP debate) within the original  
thread.


> Is this aspect of POP 'well-defined' in
> the RFCs? This is not a rhetorical question, I really don't know.

No, of course not.

The POP protocol defines how a client and a server communicate, and  
what the client may ask the server to do thru a limited set of well- 
defined commands.
And so does the IMAP protocol too, no more no less.

The client configuration may allow to automate some command sequences  
emitted by the client, so that the user doesn't have to perform those  
commands manually; but this clearly is outside of the client/server  
protocols.

The current base specifications of the POP and IMAP protocols are  
available at, respectively:

	http://www.rfc-editor.org/rfc/rfc1939.txt
	http://www.rfc-editor.org/rfc/rfc3501.txt


>> What if user 1 at MUA1 decides to delete some message today? Will
>> user 2 on MUA2 still see that message when connecting 10 days later?
>> Of course, if user 1 and user 2 happen to be the same user, then that
>> user won't be surprised.
>
> Since he obviously wasn't talking about different users, I'm really  
> not
> sure why you asked your question.

Because email users often tend to be somewhat schizophrenic...
For example: hey! why are my messages marked as read by Thunderbird? I  
just had a quick look at them thru webmail in a cybercafé?!?

But yes, agreed: to better convey my idea, I should have written  
"souldn't be surprised" instead of "won't be surprised".


> Multiple users accessing the same IMAP account/folders obviously
> requires some thought and planning (and well-defined permissions) to
> make work correctly.
>
>> But then neither would he have been surprised if using two distinct
>> POP clients.
>
> I cannot count how many times I've had to explain to $user that the  
> fact
> that the reason they just had to redownload 5000 messages (for the 3rd
> time in a year?) is a good reason NOT to use this option, and that  
> they
> should use IMAP.

Do you mean that those re-downloads occur frequently and  
"spontaneously"?
This should normally not happen, and it may be worth to somewhat  
investigate.
For example, perhaps are your users addicted to alt-ctrl-del  
sequences? ;-)
More seriously: are the clients bug-free? may it happen that your  
users sometimes work thru poor communication channels? is the server  
consistent with the UIDLs? why do your POP users leave so many  
messages on the server? etc.


> So, yes, $POPuser can certainly be surprised when this 'feature' of  
> POP
> doesn't work as expected.

Again, this has nothing to do with the POP protocol; this is just a  
client setting, an often misunderstood one.

BTW, have you noticed those settings available on IMAP clients?
They usually begin with 'remove messages from the server when...',  
instead of 'leave messages on the server...'
These opposite formulations just reflect those opposite behaviors I  
mentioned above.
And because of that, IMAP clients often provide settings related to  
local copies of messages as well.
All those (yet more complicated) settings are often misunderstood too...


Axel



More information about the dovecot mailing list