[Dovecot] Idea: POP3 deletion as a flag

[Gedalya]

On 05/03/2013 10:13 PM, Professa Dementia wrote:
> On 5/3/2013 3:44 PM, Timo Sirainen wrote:
>> On 4.5.2013, at 1.27, Kelsey Cummings <kgc at corp.sonic.net> wrote:
>>
>>> On 2013-05-03 09:14, Timo Sirainen wrote:
>>>> GMail doesn't delete mails when POP3 client issues a DELE command for
>>>> it. Instead they just become invisible for future POP3 sessions, but
>>>> they still exist for IMAP/webmail. The same could be implemented
>>>> pretty easily for Dovecot:
>>>
>>> How does the usage case by your large customer differ from that 
>>> allowed by the lazy_expunge plugin?
>>
>> I didn't ask what their main reason for this was, but for me it would 
>> be: "Oops, I accidentally configured my new email client as POP3 
>> instead of IMAP, and now it deleted everything from my INBOX." With 
>> lazy_expunge the user would have to explicitly go and undelete the 
>> mails, and it would also undelete those mails that were intentionally 
>> deleted. With this feature nothing at all would go wrong on 
>> IMAP/webmail side.
>
> I agree with AJAX.  This seems to be a matter of convenience and 
> features versus privacy rights.  Do the desires of the mail handling 
> organization outweigh the privacy needs of individuals. This is a long 
> standing argument.
Ajax said that a service enabling this feature should make a strong, 
broad and clear statement about it, and I agree. I'm all in favor of 
transparency. And customer service.
>
> I am glad that this was brought up.  History is littered with 
> inventions and creations that were designed for one purpose, but 
> misused for another.
>
> It seems this mod was designed to deal with stupid users who are 
> unable to set up their email correctly, and the IT departments who are 
> too lazy to manage the situation properly.  I think this attempt to 
> make the software idiot proof will fail, however.
Writing extra code to provide better service is lazy?
You're thinking about a corporate environment. That's not the only use 
case, and usually not the largest deployment size either.
>
> There is a saying the goes something like "You cannot make anything 
> idiot proof because idiots are so ingenious."
We're trying to mitigate problems, not make the world perfect.
>
> If someone is worried about end users setting up POP accidentally and 
> deleting emails, then firewall ports 110 and 995.  Simple solution. 
> Problem solved with no inadvertent introduction of privacy and legal 
> violations.
Why firewall only ports 110 and 995? We can also just shut down the 
entire mail service and this way we have no problems at all.
>
> What worries me, is that as an end user, I now have no idea if this 
> "feature" is turned on or not.  When I specify that an email be 
> deleted from the server, I expect that it is *deleted*.  I feel that a 
> feature like this is ripe for abuse.
Email is ripe for abuse. I can read every single email on the mail 
server. That's just wrong. The alternative is to let users manage their 
own private keys... yeah right. We just agreed that users are stupid, 
didn't we?
Emails are not private from the eyes of anyone accessing the server, 
that's fundamentally the case, I do not need Timo's help if I want to 
commit identify theft, or to disobey a user's DELE command. I can mirror 
/ archive every single email in an infinite number of ways, thanks to 
the beauty of the UNIX philosophy. And if what I wanted was to illegally 
hold on to user data, as opposed to doing what my users want me to do - 
which would be the case in this discussion, then the more sensible way 
to archive everything is at the MTA level. And if I want to do that 
without telling anyone, who is to stop me?
Users implicitly trust me, and I ought to be nice enough and, as Ajax 
said, transparent. That's very important.

>
> Is there any way for the end user to know that this feature is turned 
> on?  What if a hacker got access to the server and changed the value 
> of this setting?  As pointed out by AJAX, POP3 comes with an 
> expectation of privacy.  There should be some way that the end user 
> gets notified that his deleted POP emails are not actually deleted.
An attacker breaking into the system becomes equal to me in his powers, 
see above.
>
> If Timo wants to add these features to private copies of the software 
> for specific organizations, that is a matter between him, his client 
> and the law.  However, I do not feel it belongs in the mainstream 
> release.
>
> Dem