add a "delete after" option

Hi Bill,

Thanks for taking out time to report the bug and help make Ubuntu server better.

We appreciate the suggestions of new features but I am afraid that we work on the packaging of upstream source[1] for Ubuntu.

Such new feature requests and suggestions are worth reporting upstream and once they're added there, we can pick it from there and provide it via the packages we ship. So if it's not too much to ask, do you think you can rather report this upstream[1] instead and get their opinion on this?

[1]: https://gitlab.com/fetchmail/fetchmail

Thanks, again.

Since this isn't a bug or something Ubuntu-specific but a feature request from the upstream, I am marking this as "Invalid", but should you feel differently, please let us know and we can work something out.

Bill, thanks for the proposal. I'll answer as upstream maintainer. The former fetchmail maintainer, Eric S. Raymond, years go, decided against this feature ("do one job well"), but I am open to it.

Technically however I need to change the .fetchids format, so this is release 7.0 business, meaning many months out.

Please re-file this feature request (without the privacy "reason") as new issue here: https://gitlab.com/fetchmail/fetchmail/-/issues and then reference it from this launchpad request.

Notes: The use case of truncating history is also valid for me, OTOH you don't know whether your mail service provider will just put a delete mark on your mail and hide it from your view without actually erasing it, or for some legislations is under some secret surveillance order and blind carbon copies the prosecutor or intelligence, so there is no privacy gain.

For real privacy, e-mail is likely a lost cause and even if you encrypt end-to-end there's a truckload of metadata available to everyone.

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

For the record, I should mention that I just noticed this is covered in the FaQ:

https://www.fetchmail.info/fetchmail-FAQ.html#G5