On Wednesday, November 17, 2004 at 22:00 Boris Anders wrote: >> Is there a but here or have I constructed my filters wrongly?
> Can't see a "logical error". Your filter seems to be correct > else it > wouldn't work on refilter. Further more, I heard from (one or two) > other user(s) similar problems (filter doesn't filter some mails, but > re-filtering work). But nobody (including you) could fine a system or > pattern yet. > So maybe you can post (or send me a pm with) your three filter here > and two mails: one which was filtered correct and one which wasn't > filterd correct (if the virus-alter mails are not that private). Actually, in total there are really a whole lot of filters there, and it proved that I did make an error in the logic. I slightly misled you on my original question, partially because of a change I had made but didn't reflect in my message. I noticed that if I add an action to the parent filter, these actions are all executed before processing any subfilters. While there is some logic to that, it was something that in my case I deemed undesirable from a 'storage' point of view. Already, incoming mail is first stored on disk temporarily while fetching from the POP3 server, then added to the Inbox, then filtered. In my situation the mailbox receives messages from 5 different anti-virus components. For each of these, I want to split the messages according to virus name for viruses and according to a number of other criteria for messages related to managing these components such as pattern update success/failure and so on. Because new viri come out every day, there will regularly be mails coming in with virus names that I didn't define rules for yet. In order to maintain some kind of order, I decided to create a folder named @Unhandled for each of the 5 AV-components. The topmost parent filters simply differentiate between the 5 AV-components. In order to avoid having each mail originating from a specific component being put in the @Unhandled folder for that component and then later on in the subfilters being moved to the final destination folder, I removed the action to move mails to @Unhandled from the topmost parent filter and added a 'catchall' subfilter to it to perform this action. What I now got bitten by, however, is that in order to organize my filters properly, I created 'container' filters with the criterium 'all messages' to hold a number of subfilters. The result of this was however, that no filters below the first 'all messages' container would get processed, regardless of whether or not any of the subfilters below it had matched. This forced me into setting 'continue processing' for the container filters. As a result, even though the messages had initially been moved to the correct folder, they got moved back to the @Unhandled folder again because they would eventually match the catchall filter at the bottom of the list for the current AV-component. By removing the catchall filter and putting the 'move to @Unhandled' folder back in the topmost parent, the filters started behaving as expected. The disadvantage of my current situation is that each and every of the 13000+ messages that arrive every day, gets put into both my Inbox and @Unhandled for the AV-component in question before getting moved to its final destination, leaving two 'deleted' copies in its wake. The 'Inbox' situation has always existed, but I had hoped that the filters would be smart enough to first determine the final list of actions-to-be-taken before executing them, which would save one deleted copy in @Unhandled for each processed message, lower the overall disk IO necessary to perform the filter and thus increase speed. This leads me to two wishes: 1) Filters should 'collect' all actions-to-be-taken and perform only the last move on multiple moves. 2) It should be possible to create a purely organizational container level (sub)filter where processing of filters further down the list occurs automatically if none of the subfilters yielded an action. -- Greetings, Maurice Windows XP 5.1 Build 2600 Service Pack 2 The Bat! v3.0.2.7; Bayes Filter Plugin v1.5.6; AJS v0.6; MyMacros 1.11a. ________________________________________________________ Current beta is 3.0.2.7 Rush | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
