[Dovecot] "leave mail on server" workaround
Hello,
POP users often keep fetched mail on server, by checking for "leave mail on server" or similar option in their client.
What would be the best way to disallow them using such approach. That is, what is the best way to force deletion of messages that have been RETRieved in a POP session at the end of that POP session?
RETRieved messages will be marked as \Seen, but since users might also use an IMAP client (e.g. webmail), it'll be dangerous to simply delete all \Seen messages in user's mailbox.
I'm all open for suggestions.
-- -- Kirill Miazine km@krot.org
Kirill Miazine put forth on 1/9/2010 6:34 PM:
Hello,
POP users often keep fetched mail on server, by checking for "leave mail on server" or similar option in their client.
What would be the best way to disallow them using such approach.
Implement storage quotas. I'd make the policy known to your users well in advance of implementing any solution to this "problem" though. Uninformed users are generally upset by unannounced changes being forced upon them.
-- Stan
Thanks for the suggestion regarding quotas, but I'm really interested in an approach I just described. I want to be able to disable the possibility to leave mail on server after download.
- Stan Hoeppner [2010-01-09 20:56]:
Kirill Miazine put forth on 1/9/2010 6:34 PM:
Hello,
POP users often keep fetched mail on server, by checking for "leave mail on server" or similar option in their client.
What would be the best way to disallow them using such approach.
Implement storage quotas. I'd make the policy known to your users well in advance of implementing any solution to this "problem" though. Uninformed users are generally upset by unannounced changes being forced upon them.
-- Stan
On Sun, 10 Jan 2010 13:57:41 +0100 Kirill Miazine wrote:
Thanks for the suggestion regarding quotas, but I'm really interested in an approach I just described. I want to be able to disable the possibility to leave mail on server after download.
Maybe you should disable POP in general an d offer IMAP only?
People who want their mail on their local computer can achive this by copiyng from the (IMAP-)folder to the local folders.
--Frank Elsner
- Kirill Miazine km@krot.org [2010-01-10 13:57]:
Thanks for the suggestion regarding quotas, but I'm really interested in an approach I just described. I want to be able to disable the possibility to leave mail on server after download.
Well, you'd have to hack the source then, and make it delete the message after retrieving it.
Or you could make something that deletes read e-mails older than X days.
-- Vegard Svanberg vegard@svanberg.no [*Takapa@IRC (EFnet)]
- Vegard Svanberg [2010-01-10 14:31]:
- Kirill Miazine km@krot.org [2010-01-10 13:57]:
Thanks for the suggestion regarding quotas, but I'm really interested in an approach I just described. I want to be able to disable the possibility to leave mail on server after download.
Well, you'd have to hack the source then, and make it delete the message after retrieving it.
Yes, that's probaby the easiest way to go. Or maybe a plugin for disallowing "leave mail on server" to force users to use IMAP?
Or you could make something that deletes read e-mails older than X days.
-- -- Kirill Miazine km@krot.org
On January 10, 2010 1:34:25 AM +0100 Kirill Miazine km@krot.org wrote:
What would be the best way to disallow them using such approach. That is, what is the best way to force deletion of messages that have been RETRieved in a POP session at the end of that POP session?
RETRieved messages will be marked as \Seen, but since users might also use an IMAP client (e.g. webmail), it'll be dangerous to simply delete all \Seen messages in user's mailbox.
These two statements seem to be in conflict. If your users might also use an IMAP client, why would you delete retrieved messages at all?
- Frank Cusack [2010-01-10 12:20]:
On January 10, 2010 1:34:25 AM +0100 Kirill Miazine km@krot.org wrote:
What would be the best way to disallow them using such approach. That is, what is the best way to force deletion of messages that have been RETRieved in a POP session at the end of that POP session?
RETRieved messages will be marked as \Seen, but since users might also use an IMAP client (e.g. webmail), it'll be dangerous to simply delete all \Seen messages in user's mailbox.
These two statements seem to be in conflict. If your users might also use an IMAP client, why would you delete retrieved messages at all?
To give them an incentive to use only IMAP ;)
Actually this is a wish of one customer, so I'm trying to figure out how much pain it will be do support such scenario.
-- Kirill
Kirill Miazine put forth on 1/10/2010 11:28 AM:
Actually this is a wish of one customer, so I'm trying to figure out how much pain it will be do support such scenario.
One customer? Why is s/he requesting this? AFAIK, all POP clients default to "delete after download". And even if there is one that defaults to "leave a copy on server" I guarantee it has an option to "delete after download".
However, regardless, these aren't motivations. The only possible legitimate motivation for wanting this ability is that a customer is eating too much disk space. The answer to that is quotas. If you goal is that you just don't want to support POP anymore but only IMAP, then you send an announcement to your customer community that you will cease supporting POP on date xx/xx/xxxx and instructions for setting up an IMAP client can be found here: http://www.your-domain.tld/imap-instructions.
Something is amiss here. I fear you are not being truthful in your account of your motivations. There is no legitimate scenario for requesting this ability. Any possible motivation you could have for wanting this feature is better properly handled by options/methods already in existence.
-- Stan
- Stan Hoeppner [2010-01-10 12:15]:
Kirill Miazine put forth on 1/10/2010 11:28 AM:
Actually this is a wish of one customer, so I'm trying to figure out how much pain it will be do support such scenario.
One customer? Why is s/he requesting this? AFAIK, all POP clients default to "delete after download". And even if there is one that defaults to "leave a copy on server" I guarantee it has an option to "delete after download".
However, regardless, these aren't motivations. The only possible legitimate motivation for wanting this ability is that a customer is eating too much disk space. The answer to that is quotas. If you goal is that you just don't want to support POP anymore but only IMAP, then you send an announcement to your customer community that you will cease supporting POP on date xx/xx/xxxx and instructions for setting up an IMAP client can be found here: http://www.your-domain.tld/imap-instructions.
Something is amiss here. I fear you are not being truthful in your account of your motivations.
What makes you fear that I'm not being truthful about my motivation? (So ou mean I'm lying, huh?) I got a question about possibility to disable "leave mail on server" at all. And since "leave mail on server" is just a client behaviour (not deleting after retrieving), I needed to explore options to accomplish this request.
On this list, I was asking about a way to best accomplish this. I was not asking for opinions on whether such behaviour is optimal, desirable etc.
There is no legitimate scenario for requesting this ability. Any possible motivation you could have for wanting this feature is better properly handled by options/methods already in existence.
IIRC Gmail has an option to delete a message after it is retrieved via POP. Regardless of whether the POP client issues DELE commands or not.
I remember having come across a POP server that had a feature (disabled by default, of course) to generate random messge ID in response to UIDL commands. The motiviation? To discourage users leaving mail on server.
Anyway, let us close this thread now before getting too much off topic.
-- -- Kirill Miazine km@krot.org
participants (5)
-
Frank Cusack
-
Frank Elsner
-
Kirill Miazine
-
Stan Hoeppner
-
Vegard Svanberg