palidin74
Posts: 4
Score: 0
Joined: 6/6/2008
Status: offline
|
Sigh... This is one of the larger headaches with Merak/Icewarp. I love this product however the SPAM reports are something that if just a bit of attention was given the management of them would be so much easier. First let me say that I am by no means an expert on this product however we have been using Merak for quite a few years and I have become rather efficent in managing it. Let me start by explaining how the actual SPAM report process works as I understand it through my own troubleshooting. Please if someone out there knows something different (or better) POST since I would LOVE TO KNOW MORE about managing this process. Here we go Basically the SPAM report is a large script (for the lack of a better word) that generates HTML code one by one for every mailbox. There are conditions that it checks (for example if SPAM reports are not enabled, set to new or all etc) agenst the mail database. Based on those conditions the script changes its output or skips that mailbox all together. This poses a question. Do you have SPAM reports enabled on the domain level? This is one of the improvement areas. In Merak you can actually turn off the SPAM functions at the domain level however the options still show at the user level? This can be quite the issue at times when troubleshooting. If this is your case then the debug mode will show it checking the mailbox in question however it will indicate there is NO SPAM to process. If both the domain and the mailbox is flagged to use the SPAM system and there are SPAM messages within the SPAM folder (typically ~SPAM) then the script will begin processing for that mailbox. There is one more condition as well i believe. If the user has the "new" option selected where the SPAM report is only to contain messages that have arrived withing the SPAM system since the last SPAM report a data comparison is done between the messages and the spamreport.dat file contained within the users SPAM folder. If the new condition is set and there are messages with a newer date than the .dat file then the report is generated and contains only those messages. If there are no messages with a newer date than the .dat file then the mailbox is skipped. Now we get into the nitty gritty of the script. At this point all conditions are met and the processing of the messages into the report begins or a condition is not met and the script moves on to another mailbox. The script then grabs the .imap or .tmp files contained within the ~SPAM and ~quarantine folders and reads them in order to insert there information into the HTML generated report. At this point you have to realize the script is reading the messages and grabbing the appropriate fields to insert into the report for the user. Here is where things can go wrong. Unlike some applications when this script runs into a problem it simply stops processing. This is where you see a handfull of users actually getting there SPAM report and a handfull that does not. The ammount of each depends on where the script dies during its processing of the mailboxes. This is where I see the largest problem with SPAM reports. Some user recieves a mail message containing code that the script simply cannot process and it halts. The only way to fix it is to delete the spam message that is interfering with the script. So comes the big question how can you find out what message is causing this? To my knowlege there is no sure fire or simple way. You have to run the debug option within merak (the button is new in 9.3.1 and higer) however the URL method that kicks off the reports has been there since the inceptoin of the SPAM report. You can run a debug in any versoin using this method (again to my knowledge). The debug option will generate HTML as the script goes through the mailboxes and processes the SPAM report. The exact order of this i am not sure, its domain by domain i know that however i believe it uses creation date within the database table. In other works if you have mailboxes 1,2,3,4 and you created mailbox 2 then 3 then 4 then 1 each of the mailboxes were added to the SQL table as you created them, this is the same order the SPAM report script goes through and generates the reports it simply grabs the users from the table and the table happens to be 2,3,4,1 since the mailboxes were created in that order. The debug output will stop on a user, thats the user where your problem message file exists. The odd thing is this, how do you know what your last user is within the report? If the script stops is that normal or is that the problem user? How i do it is simple. I run a batch file outputing to e-mail. This file basically searches all the mail directories. When if finds a spamreport.dat file it checks the date if its more than 24hrs old then i know the report did not fully run and it prompts me to run a debug and isolate where the problem resides. There is only one problem with how I do this. When a user disables there SPAM report then the dat file remains and it shows up in my batch file. So i have to check the user each time I am prompted there might by a problem and make sure the user did not disable their SPAM report legitimately. If they did i delete the dat file so i dont get prompted by the batch file again. I would love to see merak have a simple script that can let admins know if the script stops, if so at the very least notify the admin. Even more so I would love to see a "delete any SPAM message that prevents the SPAM report from completeing" option. Hope this helps, and again please if anyone out there has a better way to manage this please please let us know! Thank you
|