This goes exactly the way I didn't want: a feel of start of a flame war. I had the feeling, reading your answers, that there was some part of it that were not 100% honest (when comparing junk mail to a database). I hope this was not triggered by my poor writing style or that I misread about your intentions, and that we will come back to a more friendly discussion here.
Alexander Wirt wrote: >>>> Something like this in /etc/cron.weekly/amavisd-new would do: >>>> >>>> #!/bin/sh >>>> >>>> find /var/lib/amavis/virusmails/ -type f -mtime +30 -delete >>>> >>>> and would be very easy to add in the package. Best would be to add this in >>>> both lenny-proposed-updates and sid if possible. >>> Eh no sorry, this should be up to the administrator. >> NO! Debian should deliver software well installed and behaving >> themselves correctly in the system. > The administrator should only use software they configured correctly. I'm not > able to detect with high magic how an administrator configured their amavis. I'm talking about the default behavior here, once you install amavis and start using it. Not about any "high magic" as you say. But have you just said that amavis is not configured a correct way by default? By default, there is a /etc/amavis/conf.d/20-debian_defaults. Am I mistaking that it is you guys, maintainers of the package, that wrote it, and decided to jail in ~/virusmails? I don't see any magic here, just the default that you decided, right? That's the part that I'm discussing. The amavis package has BY DEFAULT a ~/virusmails junk destination, and I feel that BY DEFAULT it should also maintain it. Is that completely insane? >> Please realize that BY DEFAULT, amavis should behave itself and >> shouldn't fill /var. Do NOT set something disabled by default please, do >> the clean on all installation by default (with a flag to disable if you >> like it, but I think a "do not be dumb" flag is useless... maybe a "how >> many days" variable make more sense). Please keep in mind that there's >> no sane administrator that would like to have /var filled with 3 years >> of virus/spam history. My proposed solution is trivial to implement. > And totally stupid, I won't ever delete mail of other people without asking > them. Amavis is a complicated software and should used with care. Deleting > mails is dangerous and I would never do this by default. I'm not talking about normal messages here, but about spam / junk emails / virus that are potentially YEARS old and taking up some HDD space dangerously for no reason. > Any BY DEFAULT amavis does not receive any mails, you put it into your mail > setup - not the package. Which could have been one of another bug report, but considering that the upstream maintainer of postfix discarded entirely my proposal to add a /etc/postfix/conf.d (the same way Apache does, which is great for us, distribution maintainers), I didn't. Haven't you ever thought like me "how come, when I install postfix and amavis, they don't work together"? In an ideal world they would. There's nothing one should be proud of this situation, and using it as an argument in this discussion is quite astonishing to read! This is a big lack in Debian that there's no mail toaster that works correctly by default (but not really the amavis package fault here, and I don't see a solution to that issue coming anytime soon). Gerfried Fuchs wrote: > Hi! > > * Thomas Goirand <tho...@goirand.fr> [2010-02-10 15:30:42 CET]: >> Alexander Wirt wrote: >>> Eh no sorry, this should be up to the administrator. >> NO! Debian should deliver software well installed and behaving >> themselves correctly in the system. > > This includes not deleting enduser data, how well the intentions might > be. Are you calling "user data" a folder that has the name "virusmails"? In that case, why was it called that way? Why only junk is going there? If you are then pretending that stuffs in this folder are end-user data, then that means that amavis is not filtering correctly (I believe it does), then why maintaining it in Debian altogether if it's broken? > Any mailserver is "filling up the /var" with simply receiving mails. No. Any reasonably configured mailserver will have something in /var/spool for a while at least, then many administrator do the delivery elsewhere (at least I do), and the at the end, the end user will use pop and retrieve his mail. If the user doesn't, then there is a quota on his mailbox to avoid that it fills the entire disk. If after 5 days the size of the mailbox is still too big, then the emails that are waiting are discarded from the spool of the originator server, possibly sending a delayed bounce to the sender. I believe this is a very general use case here, nothing "magic" (as said above) or unusual. I have no other daemon that I run that has the behavior of Amavis that you describe (eg: continuing filling up the /var until death of the server with absolutely zero limit anywhere...). > Do > you want to promote to delete regular mail after a certain time too? > What about database servers storing data after data, also filling up > /var - do you request deleting ancient rows from those, too? Why are you trying to let me say something I never had intention to? Why are you saying that a folder called "virusmails" is equivalent to a database or a regular mail? This makes absolutely no sense and is not relevant to this discussion. Please don't argue like this, it's not helping your case or anyone. >> Please realize that BY DEFAULT, amavis should behave itself and >> shouldn't fill /var. > > Please realize that by that request you request amavis to block mails > in the first place. No, I'm asking to clean a folder that by design receives only junk (or at least should, if not, then you have an issue to solve in your server). And my proposal is to do this after a certain amount of time by default so you have enough time to get an improbable needed false-positive (make this amount of time far in the past by default if it bothers you so much), so the hard drives of a server running amavis wont get filled with junk and die. The very goal of amavis is to filter messages, isn't it? >> Please keep in mind that there's no sane administrator that would like >> to have /var filled with 3 years of virus/spam history. > > So you are calling quite a fair amount of administrators insane - good > approach. Just because something doesn't cross your mind doesn't mean > that there aren't reasons for keeping historical stuff around. Are you saying that YOU DO keep a record of 3 years of spams and virus? If you do, then you are the only one that I know. Anyway, we can discuss the default time period before deletion of the junk and could make it configurable, but... keeping 3 years of virus and spam history man... Please write back to #569150 to confirm you think it is a sane way to do things, because I can't believe that you said this is a good default behavior! >> My proposed solution is trivial to implement. > > ... and would work against the principle of least suprise: Lost > end-user data. Once more, I'm not talking about end-user data, but about a folder named after its content: "virusmails". And it's full of junks, as one may think. Why are you pretending multiple time that this is user data that we are talking about here? At the very worst case, one could describe this folder as "content that may be end-user data if the server is not doing what it was designed for, most probably because of a misconfiguration" at the very most. Certainly not just "end-user data" like you do. > Chosing the severity is up to the discretion of the package maintainer. I'm afraid it's up to the definition of the importance of bugs, not a maintainer decision: 1 critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. 4 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. 6 normal a bug that does not undermine the usability of the whole package; for example, a problem with a particular option or menu item. 7 minor things like spelling mistakes and other minor cosmetic errors that do not affect the core functionality of the package. 8 wishlist suggestions and requests for new features. If it was just a maintainer's decision, then it would be a big mess in the BTS. I'd be tempted by #1 as having a /var full because of junkmail taking all the space could lead to loosing real end user data, and render a system quite unstable. However, I thought that was easy to fix when such issue raises, so I have just put #4. My bug entry here certainly doesn't go into the "wishlist" category, as wishilist is not for solving an issue on an existing package, which there is clearly here. What's your argument to say it should go as "wishlist"? > If you disagree with that please add reasoning, and if you still > disagree you are free to bring it up with the tech committee. I hope we are both smart enough and can exchange ideas without the need of a committee, and be friendly! See above for my reasoning, and let me know what you think is wrong in what I wrote. Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
