Don't fear the overflow folder. The overflow folder is your friend. It's good to have an overflow folder.
A few key things to know about the overflow folder: - odds are pretty good that everyone on this list has dealt with the overflow folder, you're not alone and there *are* answers - it is a Declude invention, so if you've disabled Declude and just use Imail, there will be no SMD files there - files going into the overflow is a good thing, because IMail chokes on too much mail - it is a good thing because Declude also watchdogs the number of IMail plus Declude related processes, and too many probably means too much CPU contention - there is a historical "mystery heap" overflow problem which led to Declude processes blowing up, and the usage of the overflow folder addresses that too - restricting the number of simultaneous Declude processes is a good thing - IMail knows nothing about the overflow folder; an instance of Declude needs to move the SMD file back into the SPOOL folder for delivery. - if you cut off inbound mail delivery, the current declude instances will finish, leaving the files in the overflow folder stranded. If this happens, either a) move them back to the spool folder manually and on the next queue run IMail will deliver them, or b) do a "manual queue run" and invoke declude with a fake SMD name, e.g. declude c:\imail\spool\Q1231231231231231.SMD which Don't give up on Declude support so easily. You really need to cover your basics first, such as figuring out your current mail volume, and whether your DNS is responding the way you think it is. I've been on this list for a couple of years and have had this problem myself. The causes were always: - Local DNS failures - DNS timeouts from using dead IP4R blacklists. - Sudden increases in mail - Mail surges caused by accepting wildcard addresses for a domain - Plain old too much mail for your hardware - Disk fragmentation; IMail and Declude drives get terribly fragmented - Log files are too big for your disk system; multiple processes trying to add a bit of text on the end of a 100 MB flat text file is surprisingly disk intensive - Log file analysis shows a bunch of errors that would lead to an answer - Declude uses too much CPU time. This last one is entirely within your control; Declude has added lots of features to control how much work it does. A few quick examples: - If you're using filter files with Declude JunkMail Pro, you really need to look at the "short circuit" processing options like SKIPIFWEIGHT and STOPATFIRSTHIT. - David Barker from Declude Support recently posted that a directive in your global.cfg "DECODE OFF" would (at the least) turn off BASE64 message body decoding, which saves CPU time two ways, the decoding itself, and by reducing the amount of text that could possibly be searched by filter files. - The directive in your virus.cfg "AVAFTERJM ON" would run your antivirus scanner after JunkMail instead of before it, and only if the message is not held as spam. This leads to viruses being held in your spam folder, but is a common choice. - Your choice of antivirus scanner can make a big difference in processing time; Matt did a heroic job of comparing scanners. Check this link to search the web mail archive for his scanner efficiency olympics (bottom line- if you choose only one scanner, choose F-Prot) : http://www.mail-archive.com/cgi-bin/htsearch?config=declude_virus_declud e_com&restrict=&exclude=&words=olympics and if you have further questions, bring them over to the Declude.Virus mailing list. Andrew 8) --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
