Re: NFS: erratic behaviour with subfilters
Hello Maurice, 1) Filters should 'collect' all actions-to-be-taken and perform only the last move on multiple moves. M because it would reduce the possibilities of what you can do with M filters right now. Would you care to elaborate on this? Why would that be true? Can you give an example of a structure of filters and subfilters with actions that would be hampered by this? I had this message marked for reply since one month ago and, to tell you the truth, I don't remember what we were talking about. If I have time during Christmas holidays, I'll try to look at the archives. -- Best regards, Miguel A. Urech (El Escorial - Spain) Using The Bat! v3.0.2.6 on Windows 2000 5.0 Service Pack 4 Current beta is 3.0.2.10 | '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/
Re: NFS: erratic behaviour with subfilters
Hello Boris, On Thu, 2 Dec 2004 20:58:36 +0100 GMT (03/12/2004, 02:58 +0700 GMT), Boris Anders wrote: What you are looking for with these container filters are not filters at all, I would think. You need a group name functionality. BA Yes, container filters aren't filters, but dummy filter. They should BA be there, to keep order, but don't work as filter. Yes, then we agree. The second solution (which is not yet tested) is, to introduce a control filter: I would consider this far too complicated to be acceptable. BA Maybe you feel it as a (too complicated) workaround - but since BA container filters or group name functionality isn't implemented it's BA the only way to do so, right? A change in functionality was suggested. So it is not a way to do it now. I'd suggest the functionality change to go into the direction of an entry in the filterlist that isn't a filter. -- Cheers, Thomas. If they don't want us to drink and drive, why do you have to have a driver's license to buy beer? Message reply created with The Bat! 3.0.2.4 Rush under Chinese Windows 98 4.10 Build A Current beta is 3.0.2.10 | '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/
Re: NFS: erratic behaviour with subfilters
Hello Boris, On Thu, 18 Nov 2004 14:05:05 +0100 GMT (18/11/2004, 20:05 +0700 GMT), Boris Anders wrote: 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. BA Yes, this is a nice wish. I have the same problem like you. A filter BA as container filter (with all messages condition) can make problems. BA So a container filter would be nice. BA But I think there are workarounds - I use the first one and in BA this moment I think there is a second one. BA Imagine: BA Filter A - container filter BAFilter A1 - condition: From Maurice BAFilter A2 - condition: From Boris BA Filter B BAFilter B1 BAFilter B2 BA First, I set the condition of A to all message - but this brought BA troubles, because then Filter B will never touched. Also the solution BA continue filtering isn't that good, because then changes from A, A1 BA and A2 could undo by B, B1 or B2. True. But A and B are catch-all filters. Let's assume A' and B' are the action performed by these filters (for example moving the message to a default folder). The logic is this: 1.) continue processing disabled A(True) + B (True) = A' (Since A matched, B is not processed. It could also be false) All messages are matched with the catch-all. 2.) continue processing enabled A(True) + B(True) = B' Here it doesn't matter whether A is matched, as the B will always be processed and it will always match. What you are looking for with these container filters are not filters at all, I would think. You need a group name functionality. When a member of that group (a sub-filter) has found a match, there could be setting disable/enable processing with other groups. BA The second solution (which is not yet tested) is, to introduce a BA control filter: I would consider this far too complicated to be acceptable. -- Cheers, Thomas. Personnel executives of 100 major corporations were asked for stories of unusual behavior by job applicants. 10. ... stretched out on the floor to fill out the job application. Message reply created with The Bat! 3.0.2.4 Rush under Chinese Windows 98 4.10 Build A Current beta is 3.0.2.10 | '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/
Re: NFS: erratic behaviour with subfilters
Hello Thomas, Thomas Fernandez wrote (in mid:[EMAIL PROTECTED]): 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. Yes, this is a nice wish. I have the same problem like you. A filter as container filter (with all messages condition) can make problems. So a container filter would be nice. But I think there are workarounds - I use the first one and in this moment I think there is a second one. Imagine: Filter A - container filter Filter A1 - condition: From Maurice Filter A2 - condition: From Boris Filter B Filter B1 Filter B2 First, I set the condition of A to all message - but this brought troubles, because then Filter B will never touched. Also the solution continue filtering isn't that good, because then changes from A, A1 and A2 could undo by B, B1 or B2. True. But A and B are catch-all filters. Let's assume A' and B' are the action performed by these filters (for example moving the message to a default folder). The logic is this: 1.) continue processing disabled A(True) + B (True) = A' (Since A matched, B is not processed. It could also be false) All messages are matched with the catch-all. 2.) continue processing enabled A(True) + B(True) = B' Here it doesn't matter whether A is matched, as the B will always be processed and it will always match. What you are looking for with these container filters are not filters at all, I would think. You need a group name functionality. Yes, container filters aren't filters, but dummy filter. They should be there, to keep order, but don't work as filter. The second solution (which is not yet tested) is, to introduce a control filter: I would consider this far too complicated to be acceptable. Maybe you feel it as a (too complicated) workaround - but since container filters or group name functionality isn't implemented it's the only way to do so, right? -- Regards, Boris Anders, http://www.batboard.de Current beta is 3.0.2.10 | '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/
Re: NFS: erratic behaviour with subfilters
Hello Maurice, Maurice Snellen wrote (in mid:[EMAIL PROTECTED]): 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. If I have understood correctly what you want to do I would also oppose to this wish because I think there are ways of doing what you want. They way that things are now that processing of a filter depends _only_ on the previous filters triggering or not and on the continue processing status of previous filters is the correct way of doing things. Making the processing of a filter depend on the triggering or not of filters in a lower hierarchy would break the whole purpose of the hierarchy structure. While I don't support Boris' suggestion to solve this problem with yet another checkbox (I agree with you that this would needlessly complicate things), It might be more complicate than a container only filter - but also more powerfull. As a result, there is no set of criteria (short of adding all subfilter-criteria to the parent) that allows me to group them. Well, you can add all subfilter-criteria to the parent. A solution based on parameters and/or colorgroups feels to me like dragging something in there that doesn't belong. So what? It's a workable solution, I can't see the problem. And according to (mid:[EMAIL PROTECTED]) parameters does belong to the topic :-). Having to do something to the messages (colour group) or using a parameter that gets checked in a completely unrelated filter(tree) sounds like making things more complex than they should be. I agree with you, that it /could/ be easier ... Moreover: the only reason why a colourgroup or parameter is necessary is to avoid an unwanted situation that would not have existed if we had 'container-only' parent filters. I strongly disagree here. I think colorgroups hasn't to do anything with making it possible to create a container filter. I hope that parameters can be used one day in templates and might give a few people a greate improvement. And at least, the unwanted situation is, that sub-filter is used for container filter, but they aren't coded to fulfill that function. Params give you the possiblity, to use sub-filter for container filter - which is not a bad thing at all. The fact that the only way to get filters further in the list processed if an earlier filter has an 'all messages' criterium is to set 'continue processing' on it which then introduces the problem that messages already handled by earlier subfilters might get re-handled by later filters. Solving this by using additional actions to every subfilter of the earlier 'all messages' filter as well as having to complicate the later parents in my opinion needlessly complicates matters, requires additional work for each new filter and is also error-prone because if you forget to add the additional actions to a newly created filter, thing might get broken again and you'll be bughunting in your own filters. The problem wouldn't exist, if you won't abuse sub-filter to container filter - or if you do so - why not set (logical) correct conditions (and not a simply catch all). -- Regards, Boris Anders, http://www.batboard.de 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/
Re: NFS: erratic behaviour with subfilters
On Saturday, November 20, 2004 at 12:32 Mau [M] wrote: 1) Filters should 'collect' all actions-to-be-taken and perform only the last move on multiple moves. M because it would reduce the possibilities of what you can do with M filters right now. Would you care to elaborate on this? Why would that be true? Can you give an example of a structure of filters and subfilters with actions that would be hampered by this? 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. M If I have understood correctly what you want to do I would also oppose M to this wish because I think there are ways of doing what you want. They M way that things are now that processing of a filter depends _only_ on the M previous filters triggering or not and on the continue processing M status of previous filters is the correct way of doing things. Making M the processing of a filter depend on the triggering or not of filters in M a lower hierarchy would break the whole purpose of the hierarchy M structure. While I don't support Boris' suggestion to solve this problem with yet another checkbox (I agree with you that this would needlessly complicate things), I fail to see why introducing a 'container-only' filter would seriously break the purpose of the hierarchy. True, the advantage of the hierarchy is that instead of having to go through one long list of filters where a group of filters might be partially checking for the same criteria, one can now define the criteria that a group of filters share at a higher level and thus avoid unnecessary processing of filters that would not have matched anyway. I had expected though, that besides being able to group filters because of common criteria, I would also be able to easily group filters that belong together on organizational grounds in a single container. For instance, I have a lot of TB! lists, not all of which are run on the same listserver. As a result, there is no set of criteria (short of adding all subfilter-criteria to the parent) that allows me to group them. The purpose of the 'container-only' parent filter is purely for usability to keep filters more organized: all filters pertaining to lists go in one container. A solution based on parameters and/or colorgroups feels to me like dragging something in there that doesn't belong. Having to do something to the messages (colour group) or using a parameter that gets checked in a completely unrelated filter(tree) sounds like making things more complex than they should be. The need to group filters for the purpose of usability and organizing of filters is in my opinion reason enough to make it possible. Moreover: the only reason why a colourgroup or parameter is necessary is to avoid an unwanted situation that would not have existed if we had 'container-only' parent filters. The fact that the only way to get filters further in the list processed if an earlier filter has an 'all messages' criterium is to set 'continue processing' on it which then introduces the problem that messages already handled by earlier subfilters might get re-handled by later filters. Solving this by using additional actions to every subfilter of the earlier 'all messages' filter as well as having to complicate the later parents in my opinion needlessly complicates matters, requires additional work for each new filter and is also error-prone because if you forget to add the additional actions to a newly created filter, thing might get broken again and you'll be bughunting in your own filters. -- 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/
Re: NFS: erratic behaviour with subfilters
Hello Maurice, snipped quite a bit This leads me to two wishes: 1) Filters should 'collect' all actions-to-be-taken and perform only the last move on multiple moves. As I think Boris has mentioned, that would probably be difficult to achieve with current NFS implementation. Anyway, I think I would oppose to such a wish because it would reduce the possibilities of what you can do with filters right now. 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. If I have understood correctly what you want to do I would also oppose to this wish because I think there are ways of doing what you want. They way that things are now that processing of a filter depends _only_ on the previous filters triggering or not and on the continue processing status of previous filters is the correct way of doing things. Making the processing of a filter depend on the triggering or not of filters in a lower hierarchy would break the whole purpose of the hierarchy structure. Now, I said I think you can achieve what you want without any changes to the way things are now. Boris has already pointed the use of parameters but, apparently, there is some bug in the use of parameters. I don't know, I have not tested. But maybe it is also that Boris has suggested the use of parameters in a slightly different way that I would do it. What I would do is: Filter A (set to continue processing) Sub-Filter A1 (whatever action + set parameter P) Sub-Filter A2 (whatever action + set parameter P) Filter B (whatever condition + parameter P NOT set) Sub-Filter B1 Sub-Filter B2 I there is a bug in the use of parameters, then a I would use a colour group instead. I have not tested but it should work. -- Best regards, Miguel A. Urech (El Escorial - Spain) Using The Bat! v3.0.2.6 on Windows 2000 5.0 Service Pack 4 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/
Re: NFS: erratic behaviour with subfilters
Hello MAU, Mau wrote (in mid:[EMAIL PROTECTED]): 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. If I have understood correctly what you want to do I would also oppose to this wish because I think there are ways of doing what you want. Yes, there are ways of doing so - but how comfortable and difficult are they? In generals there seems two ways of doing this: With params (color groups, ...) or with spezial condition in container filter. Second solution is not good, because you have make changes twice (in subfilter and container filter) and first solution is better but difficult (I think that not everybody realize that container filter could be done with this solution). So this wish wouldn't reduce the possibilities of NFS, but make them more comfortable. In fact of this, I would say implement it if it's less work, implement it later if its much work. Maybe one word about implementation: I think it could be done in two different ways: 1) A option in sub-filter: [X] Stop continue processing with other filter 2) Make it possible, to add container filter which has the condition (by design) one of the subfilter-condition matches. This condition maybe shown in conditions (Subfilter(s) matches) - and must be auto-updated. I don't know what is easier to implement, but 1) seems to be more powerfull? Boris has already pointed the use of parameters I might ask you if you had the same idea independent of me? there is some bug in the use of parameters. I don't know, I have not tested. :-( - it wouldn't take much time: Import my posted filter, check if it's correct (did I make a mistake?), select a message and test filter. A short notice (maybe in bugtracker) would be nice. What I would do is: Filter A (set to continue processing) Sub-Filter A1 (whatever action + set parameter P) Sub-Filter A2 (whatever action + set parameter P) Filter B (whatever condition + parameter P NOT set) Sub-Filter B1 Sub-Filter B2 Hm, interessting. In this way you save one filter (A3), right? But on the other side, you have to add one action per subfilter. Did I miss something? I there is a bug in the use of parameters, then a I would use a colour group instead. I have not tested but it should work. Wow, good idea. Why didn't I have it? -- Regards, Boris Anders, http://www.batboard.de 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/
Re: NFS: erratic behaviour with subfilters
Hello Boris, 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. If I have understood correctly what you want to do I would also oppose to this wish because I think there are ways of doing what you want. Yes, there are ways of doing so - but how comfortable and difficult are they? In generals there seems two ways of doing this: With params (color groups, ...) or with spezial condition in container filter. Second solution is not good, because you have make changes twice (in subfilter and container filter) and first solution is better but difficult (I think that not everybody realize that container filter could be done with this solution). So this wish wouldn't reduce the possibilities of NFS, but make them more comfortable. In fact of this, I would say implement it if it's less work, implement it later if its much work. Maybe one word about implementation: I think it could be done in two different ways: 1) A option in sub-filter: [X] Stop continue processing with other filter 2) Make it possible, to add container filter which has the condition (by design) one of the subfilter-condition matches. This condition maybe shown in conditions (Subfilter(s) matches) - and must be auto-updated. I don't know what is easier to implement, but 1) seems to be more powerfull? If I understand you correctly I would still oppose to this wish. It apparently makes things easier but I think it make following the logic of filters more complex and it doesn't introduce any real benefit (i.e. something that can't be done now). Boris has already pointed the use of parameters I might ask you if you had the same idea independent of me? Yes, because that is exactly one of the reasons parameters for filters were introduced. there is some bug in the use of parameters. I don't know, I have not tested. :-( - it wouldn't take much time: Import my posted filter, check if it's correct (did I make a mistake?), select a message and test filter. A short notice (maybe in bugtracker) would be nice. What I meant is that I have not tested enough the use of parameters in general to see if there are any possible bugs. Hm, interessting. In this way you save one filter (A3), right? But on the other side, you have to add one action per subfilter. Did I miss something? No, you didn't miss anything. I there is a bug in the use of parameters, then a I would use a colour group instead. I have not tested but it should work. Wow, good idea. Why didn't I have it? Don't ask me ;-) -- Best regards, Miguel A. Urech (El Escorial - Spain) Using The Bat! v3.0.2.6 on Windows 2000 5.0 Service Pack 4 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/
Params-Bug in NFS? (was: NFS: erratic behaviour with subfilters)
Hello Boris,
Boris Anders wrote (in mid:[EMAIL PROTECTED]):
I don't know if there is a logical error in my idea, but I try this
immediately after send this message.
Ok - I faild. But I think because of a bug in set user params and
additional params since (including) 3.0.16: So here is my BugReport:
Since version 3.0.16 set user params doesn't work. While following
filter works fine in 3.0.15, it fails in (and higher than) 3.0.16:
TB! Message Filter
beginFilter
UID: [F5AA0302.01C4CE84.0AF9A79C.1230F80E]
Name: A
Filter: {\0D\0A\20`21\0D\0A}
UserParam param A value 1
MarkRead
IsActive
Ignore
endFilter
1
beginFilter
UID: [07DA539C.01C4CE85.5354944A.3B79D379]
Name: B
Filter: {\0D\0A\20`27`A`0`1\0D\0A}
MarkUnread
IsActive
Ignore
endFilter
Can you confirm or tell my where my error is? I also opend a BR:
https://www.ritlabs.com/bt/view.php?id=4063
--
Regards,
Boris Anders, http://www.batboard.de
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/
Re: NFS: erratic behaviour with subfilters
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/
Re: NFS: erratic behaviour with subfilters
Hallo Maurice, On Thu, 18 Nov 2004 13:05:31 +0100GMT (18-11-2004, 13:05 +0100, where I live), you wrote: MS By removing the catchall filter and putting the 'move to @Unhandled' MS folder back in the topmost parent, the filters started behaving as MS expected. What if you use a condition to that parent filter, but no action? I've got filters like that and they perform as intended (I think), however I don't have any subfilters for them -- Groetjes, Roelof I was the kid next door's imaginary friend. The Bat! 3.0.2.7 Windows XP 5.1 Build 2600 Service Pack 2 1 pop3 account, server on LAN pgp5BbCpPkmha.pgp Description: PGP signature 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/
Re: NFS: erratic behaviour with subfilters
Hello Maurice, Maurice Snellen wrote (in mid:[EMAIL PROTECTED]): Is there a but here or have I constructed my filters wrongly? Can't see a logical error. Actually, in total there are really a whole lot of filters there, and it proved that I did make an error in the logic. So there is/was no bug in NFS? 1) Filters should 'collect' all actions-to-be-taken and perform only the last move on multiple moves. Don't know, but I think 9Val would have a lot of work to fulfill this wish, because I think this is a design problem/wish. Further more the advantages seem to be small - means only someone one with a simalar filtering and a lot of message would profit from it. And at last, if your second wish would be fulfilled you could avoid the duplicate in changing filter system. So I can see the sense of this wish, but wouldn't support it. 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. Yes, this is a nice wish. I have the same problem like you. A filter as container filter (with all messages condition) can make problems. So a container filter would be nice. But I think there are workarounds - I use the first one and in this moment I think there is a second one. Imagine: Filter A - container filter Filter A1 - condition: From Maurice Filter A2 - condition: From Boris Filter B Filter B1 Filter B2 First, I set the condition of A to all message - but this brought troubles, because then Filter B will never touched. Also the solution continue filtering isn't that good, because then changes from A, A1 and A2 could undo by B, B1 or B2. The first solution is: Set the condition of A not to all messages but Conditions A1 or Conditions A2. In this example, condition of filter a should be From Maurice OR From Boris. The disadvantage of this solution: For every change/addition in a Subfilter condition must be done in container filter too. But: It works, at least for me. :-). The second solution (which is not yet tested) is, to introduce a control filter: Filter A - container filter Filter A1 Filter A2 Filter A3 - control filter Filter B Filter B1 Filter B2 In this case, in Filter A [X] continue filtering must be checked. Filter A3 has condition All messages and action set user param. Filter B has condition user param is. E.g. A message receive, and is catched by Filter A (because all messages). If A1 or A2 matched, A3 doesn't and the param is emtpy - as a result of this Filter B doesn't match and therefor not undo actions of A, A1 or A2. But if A1 and A2 doesn't match, A3 matches and set the param (e.g.) Continue to 1. And because param Continue is 1 Filter B matches. I don't know if there is a logical error in my idea, but I try this immediately after send this message. The advantage would be clear: You don't have to modify container filter if subfilter changes but only create once one more subfilter. Of course, if we had a container filter, it would be best and easiest :-). -- Regards, Boris Anders, http://www.batboard.de 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/
Re: NFS: erratic behaviour with subfilters
Hello Maurice, Maurice Snellen wrote (in mid:[EMAIL PROTECTED]): 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). Maybe I or somebody else can reproduce the bug or (even) find the pattern? (And if the pattern is known 9Val isn't that far away, I hope ... :-). -- Regards, Boris Anders, http://www.batboard.de 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/
