[Dovecot] Question about the pop3 feature "leave messages on server for a certain period of time"
Hi all
I am missing something on the the pop3 "leave messages" rationale.
Although the UIDL feature solves for the MUA the problem "whch mails should be downloaded", how the duration that these mails should be kept on server, say 10 days for one MUA and 20 days for another MUA for the same account, is resolved on the server?
thanks in advance
-- ΔΗΜΗΤΡΙΟΣ ΚΑΡΑΠΙΠΕΡΗΣ ΤΕΧΝ. ΥΠ. ΣΥΖΕΥΞΙΣ
ΕΛΛΗΝΙΚΗ ΔΗΜΟΚΡΑΤΙΑ - Ν. ΘΕΣΣΑΛΟΝΙΚΗΣ ΔΗΜΟΣ ΘΕΣΣΑΛΟΝΙΚΗΣ - Δ/ΝΣΗ ΟΡΓΑΝΩΣΕΩΣ & ΜΕΘΟΔΩΝ 2310 - 257844 fax 2310 - 244965
Hi,
if I understand correctly, this feature is 100% client side, so the server does nothing at all. When client connects to the server, the client checks mails date and deletes some of them based on its own settings.
HTH
El Viernes 11 Septiembre 2009 a las 10:57, Δημήτριος Καραπιπέρης escribió:
Hi all
I am missing something on the the pop3 "leave messages" rationale.
Although the UIDL feature solves for the MUA the problem "whch mails should be downloaded", how the duration that these mails should be kept on server, say 10 days for one MUA and 20 days for another MUA for the same account, is resolved on the server?
thanks in advance
-- Joseba Torre. Vicegerencia de TICs, área de Explotación
Hi I can clearly understand this, but what if we have two MUAs with different time period settings on the same account , 10 days the first and 20 days the second. The first when it will be connected on the 10th day it will delete on server all messages, so the second will not get anything at all Correct?
D.
if I understand correctly, this feature is 100% client side, so the server does nothing at all. When client connects to the server, the client checks mails date and deletes some of them based on its own settings.
HTH
El Viernes 11 Septiembre 2009 a las 10:57, Δημήτριος Καραπιπέρης escribió:
Hi all
I am missing something on the the pop3 "leave messages" rationale.
Although the UIDL feature solves for the MUA the problem "whch mails should be downloaded", how the duration that these mails should be kept on server, say 10 days for one MUA and 20 days for another MUA for the same account, is resolved on the server?
thanks in advance
-- ΔΗΜΗΤΡΙΟΣ ΚΑΡΑΠΙΠΕΡΗΣ ΤΕΧΝ. ΥΠ. ΣΥΖΕΥΞΙΣ
ΕΛΛΗΝΙΚΗ ΔΗΜΟΚΡΑΤΙΑ - Ν. ΘΕΣΣΑΛΟΝΙΚΗΣ ΔΗΜΟΣ ΘΕΣΣΑΛΟΝΙΚΗΣ - Δ/ΝΣΗ ΟΡΓΑΝΩΣΕΩΣ & ΜΕΘΟΔΩΝ 2310 - 257844 fax 2310 - 244965
Le 11 sept. 2009 à 12:07, Δημήτριος Καραπιπέρης a
écrit :
Hi I can clearly understand this, but what if we have two MUAs with
different time period settings on the same account , 10 days the first and 20 days the second. The first when it will be connected on the 10th day it will delete
on server all messages, so the second will not get anything at all Correct?
Yes.
The server doesn't know anything about MUAs configuration: it just
honors DELE commands.
The same way, a MUA is unaware of another MUA's configuration, and
will thus send its DELE commands depending on its own settings (and
algorithms).
Axel
Δημήτριος Καραπιπέρης escreveu:
Hi I can clearly understand this, but what if we have two MUAs with different time period settings on the same account , 10 days the first and 20 days the second. The first when it will be connected on the 10th day it will delete on server all messages, so the second will not get anything at all Correct?
IMHO, the 'leave messages on server' is a completly fucked up and
stupid way of trying to do something that IMAP4 does very well, intelligently and RFC-based.
If you need to use different MUAs to check the same account, you
really should consider using IMAP4. You'll have message flagging stored on server (read messages, new messages, replied ones) ... you can even configure your MUA to store sent messages on a IMAP4 folder and see those sent messages from MUA1 when you access the mailbox on MUA2 !!!
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it
Le 11 sept. 2009 à 22:59, Leonardo Rodrigues a écrit :
Δημήτριος Καραπιπέρης escreveu:
Hi I can clearly understand this, but what if we have two MUAs with
different time period settings on the same account , 10 days the first and 20 days the second. The first when it will be connected on the 10th day it will delete
on server all messages, so the second will not get anything at all Correct?IMHO, the 'leave messages on server' is a completly fucked up and
stupid way of trying to do something that IMAP4 does very well,
intelligently and RFC-based.
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.
Saying that one behavior is fucked up and the other a very clever one
perhaps tends to be a matter of faith.
If you need to use different MUAs to check the same account, you
really should consider using IMAP4. You'll have message flagging
stored on server (read messages, new messages, replied ones) ... you
can even configure your MUA to store sent messages on a IMAP4 folder
and see those sent messages from MUA1 when you access the mailbox on
MUA2 !!!
Faith again...
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. But then neither would he have been surprised
if using two distinct POP clients.
But I'm sure digressing here... ;-) Axel
On 9/11/2009, Axel Luttgens (AxelLuttgens@swing.be) 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. Is this aspect of POP 'well-defined' in the RFCs? This is not a rhetorical question, I really don't know.
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.
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.
So, yes, $POPuser can certainly be surprised when this 'feature' of POP doesn't work as expected.
--
Best regards,
Charles
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
Axel Luttgens escreveu:
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.
Starting the POP vs IMAP war was not my intention and i really would
like to say i'm sorry for that. My intention was to show the OP that, in the proposed scenario (same user with multiple MUAs trying to use leave message on server and have a intelligent behavior of that client-side feature), working with IMAP would a better choice (and smart one, in MY opinion), because keeping messages synced between several MUAs (let's not forget webmail is a pretty common second MUA used by users, usually a IMAP MUA) and server is part of IMAP protocol and does not depends on MUA behaviors or 'algorithms'. Everything is part of IMAP protocol, the $imapuser could even change MUA how many times he wants to and there would be no accidental loss of messages.
Of course if some IMAP MUA has some client-side feature configured,
like 'delete messages older than N days' configured, we can have some messages being deleted despite of user's will ... but that would NOT be an accidental loss of messages, that would be a EXPECTED loss of messages because of some MUA configuration.
All the 'leave message on server' used by POP clients is NOT part of
the POP protocol (yes i know POP is pretty well RFC-defined, but not those client-side features, as well as some IMAP client-side features are not RFC-defined as well).
The major problem here seems to be the fact that for the POP3 server
(dovecot or any other), the 'leave messages on server' feature simply does not exists. It may be guessed by the 'RETR' not followed by 'DELE' which usually happens, but that would be just a guess. There's no way to the server to control what will happen with that client-side feature and different MUAs accessing the same mailbox with POP3. The proposed of used the expire plugin would solve a different situation, not the initially proposed one.
I use IMAP4 in some situations and use POP3 in others as well. I
think IMAP4 is a better protocol nowadays, with fast internet connections and storages on server becaming cheaper each day. But it doesnt means POP3 is dead. But in some situations, like users who really needs the 'leave messages on server' feature, using pop3 is not a smart decision anymore. Which doesnt means everybody should stop using POP3 and changing to IMAP4 ....
Dimitrios, i really think you'll have a hard time trying to find a
server-side feature to control that mess of using leave messages on server with different MUAs by the simply fact that, in the server side, that thing simply does not exist.
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it
O/H Leonardo Rodrigues έγραψε:
Axel Luttgens escreveu:
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.
Starting the POP vs IMAP war was not my intention and i really would like to say i'm sorry for that. My intention was to show the OP that, in the proposed scenario (same user with multiple MUAs trying to use leave message on server and have a intelligent behavior of that client-side feature), working with IMAP would a better choice (and smart one, in MY opinion), because keeping messages synced between several MUAs (let's not forget webmail is a pretty common second MUA used by users, usually a IMAP MUA) and server is part of IMAP protocol and does not depends on MUA behaviors or 'algorithms'. Everything is part of IMAP protocol, the $imapuser could even change MUA how many times he wants to and there would be no accidental loss of messages.
Of course if some IMAP MUA has some client-side feature configured, like 'delete messages older than N days' configured, we can have some messages being deleted despite of user's will ... but that would NOT be an accidental loss of messages, that would be a EXPECTED loss of messages because of some MUA configuration.
All the 'leave message on server' used by POP clients is NOT part of the POP protocol (yes i know POP is pretty well RFC-defined, but not those client-side features, as well as some IMAP client-side features are not RFC-defined as well).
The major problem here seems to be the fact that for the POP3 server (dovecot or any other), the 'leave messages on server' feature simply does not exists. It may be guessed by the 'RETR' not followed by 'DELE' which usually happens, but that would be just a guess. There's no way to the server to control what will happen with that client-side feature and different MUAs accessing the same mailbox with POP3. The proposed of used the expire plugin would solve a different situation, not the initially proposed one.
I use IMAP4 in some situations and use POP3 in others as well. I think IMAP4 is a better protocol nowadays, with fast internet connections and storages on server becaming cheaper each day. But it doesnt means POP3 is dead. But in some situations, like users who really needs the 'leave messages on server' feature, using pop3 is not a smart decision anymore. Which doesnt means everybody should stop using POP3 and changing to IMAP4 ....
Dimitrios, i really think you'll have a hard time trying to find a server-side feature to control that mess of using leave messages on server with different MUAs by the simply fact that, in the server side, that thing simply does not exist.
Leonardo, I am pretty sure , years now, that IMAP4 is better suited for my needs and I am trying to change my organizations ethos, well established for years now. Centralized controlled mechanism in terms of e-mail usage, is by all means more convenient for the simple reason that everyone wants his e-mail corpus available from everywhere. Thank u all for your replies.
D.
On Fri, 2009-09-11 at 11:57 +0300, Δημήτριος Καραπιπέρης wrote:
I am missing something on the the pop3 "leave messages" rationale.
Although the UIDL feature solves for the MUA the problem "whch mails should be downloaded", how the duration that these mails should be kept on server, say 10 days for one MUA and 20 days for another MUA for the same account, is resolved on the server?
I guess you could configure Dovecot to delete mails older than n days with expire plugin: http://wiki.dovecot.org/Plugins/Expire
But I've no idea if it's really a good idea to do that. Some clients might freak out. Oh and expire plugin would delete messages regardless of whether client has ever even downloaded them.
O/H Timo Sirainen έγραψε:
On Fri, 2009-09-11 at 11:57 +0300, Δημήτριος Καραπιπέρης wrote:
I am missing something on the the pop3 "leave messages" rationale.
Although the UIDL feature solves for the MUA the problem "whch mails should be downloaded", how the duration that these mails should be kept on server, say 10 days for one MUA and 20 days for another MUA for the same account, is resolved on the server?
I guess you could configure Dovecot to delete mails older than n days with expire plugin: http://wiki.dovecot.org/Plugins/Expire
But I've no idea if it's really a good idea to do that. Some clients might freak out. Oh and expire plugin would delete messages regardless of whether client has ever even downloaded them.
Hi there
Definitely imap4 is more sophisticated protocol offering many useful features. By no means did I try to compare pop3 versus imap. I am using imap , I have imap servers configured and I suggest to everyone to use imap. I just had this question regarding multiple MUA's configuration on the option "leave messages on server" on the same account, and if there was an option to cease the mess that different time period setting (on DELE command) can cause..
thanks for your replies Dimitrios
Δημήτριος Καραπιπέρης wrote:
O/H Timo Sirainen έγραψε:
On Fri, 2009-09-11 at 11:57 +0300, Δημήτριος Καραπιπέρης wrote:
I am missing something on the the pop3 "leave messages" rationale.
Although the UIDL feature solves for the MUA the problem "whch mails should be downloaded", how the duration that these mails should be kept on server, say 10 days for one MUA and 20 days for another MUA for the same account, is resolved on the server?
I guess you could configure Dovecot to delete mails older than n days with expire plugin: http://wiki.dovecot.org/Plugins/Expire
But I've no idea if it's really a good idea to do that. Some clients might freak out. Oh and expire plugin would delete messages regardless of whether client has ever even downloaded them.
Hi there
Definitely imap4 is more sophisticated protocol offering many useful features. By no means did I try to compare pop3 versus imap. I am using imap , I have imap servers configured and I suggest to everyone to use imap. I just had this question regarding multiple MUA's configuration on the option "leave messages on server" on the same account, and if there was an option to cease the mess that different time period setting (on DELE command) can cause..
No. Whichever deletes first deletes the message for good.
~Seth
participants (8)
-
Axel Luttgens
-
Charles Marcus
-
Joseba Torre
-
Leonardo Rodrigues
-
Seth Mattinen
-
Timo Sirainen
-
Δημήτριος Καραπιπέ ρης
-
Δημήτριος Καραπιπέρης