I appreciate everyone's quick response. First I will address the privacy matter.
In the infosec discipline, we have the "principle of least priviledge", which essentially means it's a bad idea to grant more access than what's needed for the task. If someone only needs 90 days of server storage per message, why should the server admins have the priviledge of seeing further back? It makes no sense. As far as not knowing what the email service provider (ESP) does, that's indeed true, but this does not eliminate the security benefit for three reasons: 1) [mass surveillance case] The ESP may publish a retention policy that contractually obligates them. They may opt not to comply but it's still a security benefit to place the ESP in a position of being out of compliance should they retain "deleted" email beyond a threshold that the user controls. The state of non-compliance greatly limits how the ESP uses the data because getting caught compromises their bottom line. Yahoo was dragged into one court after it provided evidence in another court that wasn't supposed to exist per the privacy policy. It makes no sense to give up this protection. 2) [targeted surveillance case] In the case of warranted, targeted surveillance which overrides retention policy, data deleted before the warrant is served is effectively protected. If 5+ years of email is sitting on a server when a warrant is served, the warrant can force disclosure of all that data. If only ~90 days + contractual retention are on the server when the warrant is serviced, then that's all that's available. Warrants can't be served from a time machine. 3) [targeted unwarranted surveillance case] In the case of snoops illegally probing email without a warrant or consent, they can of course exfiltrate the data they're after. Getting the data is only part of the equation. How they can use illegally obtained data is limited. If they just walk into court with that they will suffer consequences. They don't want to reveal their illegal ways to the public over a small case. It's a very costly hand to play. They will look for plausible ways to obtain the data legally and go that route (parallel construction). If fetchmail needlessly leaves data on the server, it creates an attack surface for parallel construction. > Please re-file this feature request (without the privacy "reason") as new issue here: https://gitlab.com/fetchmail/fetchmail/-/issues I cannot access gitlab.com because I am blocked by a variety of Tor- hostile MACFANG-dependant mechanisms. In as open and free world, indeed bugs should be reported as upstream as possible. "Possible" is the keyword as otherwise public projects are making their way into access- restricted forges like gitlab.com more and more. There are many reasons why gitlab.com should be avoided expressed here: https://git.sdf.org/humanacollaborator/humanacollabora/src/branch/master /gitlab-dot-com.md -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1924618 Title: add a "delete after" option To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fetchmail/+bug/1924618/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
