We've been plagued by a very large (1.7 GB) bounce lately and wondered if newer amavisd-news are smarter about this:
Basically what happens is: postfix hands mail over to amavis who hands it over to clamav. Clamav spends so much time attempting to scan the file that postfix times out, gives up and puts the offending mail in deferred. The copy of the mail hangs around in various tmp-directories instead of being deleted. Then postfix tries again. Clamav takes too much time, postfix times out, gives up, and now there are *two* copies of the mail in various tmp-directories. Repeat until disk full. Then the flow of mail stops and the flow of phonecalls begin. The workaround is to shut down amavis, clamav, postfix, delete (postsuper -d) the offending mail, hunt down and delete the copies in the various tmp-directories, turning everything back on and cross fingers. An elegant fix would be for postfix to say "no way will I be able to deliver this" and shunt it into the hold-queue for the postmaster to deal with. What amavis and friends need to do is discover somehow when this happens, and break the loop (and clean up the messages that postfix gives up on). I'll eventually be upgrading anyway but a solution for the above problem might speed up things. HM ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
