Craig, > Feb 2 00:33:21 mx1 amavis[75326]: (75326-01) Exceeded storage quota > 279252000 bytes by do_ascii; last chunk 51216 bytes > Feb 2 00:33:21 mx1 amavis[75326]: (75326-01) Decoding of p1163 (ASCII > English text) failed, leaving it unpacked: do_ascii: Exceeded storage quota > 279252000 bytes by do_ascii; last chunk 51216 bytes > > With this as the last amavis log entry: > > Feb 2 00:35:41 mx1 amavis[75326]: (75326-01) Decoding of p4420 (ASCII > English text, with very long lines) failed, leaving it unpacked: do_ascii: > Exceeded storage quota 279252000 bytes by do_ascii; last chunk 51216 bytes
Either the message really contained 4400+ components, or the uulib decoder was doing a poor job of decoding, repeatedly claiming it is able to recognize the format, but decoded it to another copy of itself (same or similar contents). Such behaviour of uulib (through Convert::UUlib) has been reported in the past, some cases were fixed in later releases of Convert::UUlib, but I wouldn't be surprised if there are more problems lurking in uulib. Make sure to use a fairly recent version of Convert::UUlib. > After that, amavisd stopped responding and messages went to the deferred > queue. I had to kill the process since "amavisd reload" would not work. It's hard to say what went wrong afterwards. It could simply take a very long time to process the 4400 resulting files, or perhaps uulib corrupted process memory of the Perl interpreter. > Any attempt to requeue the messages had the same result, ... As expected. Like Gary noted, fetch the culprit message from the queue for inspection, and remove it. > Would any of following settings in the config file cause the problem? > $MAXLEVELS = 14; > $MAXFILES = 1500; > $MIN_EXPANSION_QUOTA = 100*1024; # bytes > $MAX_EXPANSION_QUOTA = 300*1024*1024; # bytes These defaults are usually just fine. In you case the (probably infinite) decoding was rightfully interrupted by these limits, so they did their job correctly. > Also what is a reasonable setting when Postfix is set to > "message_size_limit = 30000000" The above limits are reasonably generous, so I don't see an immediate need to bump up the $MAX_EXPANSION_QUOTA, unless you notice a specific example of mail where the limit was hit on an otherwise normal message. Mark ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ AMaViS-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
