So does that mean that small pure-text messages always go through with this configuration?
Sounds like we’ve learned a few things from this:
We need a warning when AV is enabled and quotas are small to strongly suggest increasing the quotas to allow for the extra file storage that Clam requires. We probably need to warn anytime hard quotas are used, since there are quite a few situations where hard quotas can cause serious and unrecoverable issues. Soft quotas don’t have this kind of issue.
We need to prevent messages from being dropped on the floor in such a circumstance–I think I see why it’s happening (Clam is failing), but I don’t like that failure mode from Clam. This could possibly be solved by using a separate /tmp partition with no quotas, but that’s really ugly and I don’t want to add that requirement to the system. There is also a --max-space option, where we could probably feed in the users quota to keep clam from trying to scan files that would lead to quota overage.
We need to figure out a way to notify the server administrator if messages are getting dropped on the floor like this. Having mail disappear, apparently without warning is a terrible problem.
I also need to test to see if this occurs on a Postfix system.
Has there been any progress on this problem with Clamav yet, I have Virtulamin Pro, Postfix and Hard quotas.
Some clients make there users mailbox 15 or 10MB and it seems clam requires about 10-20MB of tmp space alone causing the mailbox to exceed its quota and the mail being bounced.
Yes, we’re correctly bouncing messages if Clam doesn’t have enough room to process them, so they are not dropping on the floor.
Very tiny quotas will never be a good idea when Spam/AV are involved. I’d suggest backing off on your quotas a bit, or don’t use Clam. We can’t avoid it requiring space to operate, and we can’t safely process the message as any other user.
There is one way to avoid the /tmp file thing altogether, and that’s to put /tmp on a filesystem without quotas enabled. e.g. create a new partition (a pretty big one since if you’ve got untrusted users they may find that they can take advantage of the “unlimited” storage in tmp). This will make most mail processing unrestricted by quotas. I don’t necessarily recommend this, but it’s not particularly dangerous (there is a potential DoS risk, if a malicious user decided to fill /tmp, as it would be unrestricted by quotas).
So, the technical solutions to this problem are already in place. Our procmail recipes are behaving correctly. But there probably should still be some stronger advice upon creation of a user with a tiny quota, to try to make folks creating users behave correctly, too.
