On Thu, 11 Feb 2010, Alexander Wirt wrote: > Brian May schrieb am Thursday, den 11. February 2010: > > Seems to be a sensitive issue. > > If I understand the arguments correctly, the arguments for are: > > > > * email that has been classified as spam that is past X days old is > > unlikely to be useful. > > * spam accumulating in /var could bring the system to its knees if let > > go uncheck. > > * therefore it is wise to delete emails that have been classified as > > spam that are older then X days. > > * this should be the default to ensure the computer doesn't stop working. > > > > The arguments against are: > > > > * email that has been classified as spam could still be important even > > if it is past X days old. > > * everyone will have different requirements, for some people the only > > way to find out for certain is with manual checking. > > * it is better to default to the option that preserves too many emails > > rather then the option that deletes emails. > > * system monitoring should be used to ensure /var doesn't fill up. > * amavisd-new is not very usable out of the box, even if we take care about > the default you have to adapt amavisd-new to your needs > * the directory is meaned as a quarantine queue and should get managed by > the administrator not by the system. > * There is no sensible default to adapt which may not lead to data loss > * it was there for years, changing the default may be very dangerous for > everybody which uses the directory for archiving. And I don't think this > is worth a debconf question.
I am not against shipping an automated clean up script, in fact I think it is a good idea. However, thanks to the behaviour of the submitter, it won't be me who will commit a fix for this, at least not for quite a while. And certainly not while the bug is at a severity other than wishlist. For the record, there is no way I'd recommend enabling such a script by default on anything but a first install of the package. And that's always somewhat complicated to do cleanly, so IMO it would be far simpler and safer to just ship it disabled, and announce the existence of the functionality in NEWS.Debian. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
