Is the stop-clause implied in the rules?

General discussion about PopTray. You love it? You hate it? Talk about it here.

Moderators: KY Dave, jojobear99, Rdsok

Post Reply
Vanguard
Enthusiast
Posts: 40
Joined: Tue Oct 21, 2003 10:36 am

Is the stop-clause implied in the rules?

Post by Vanguard » Sat Jan 01, 2005 11:23 pm

I'm not sure how PopTray handles rules and their order. When a rule triggers on a message, does it perform its action and then continue exercising the rest of the rules against that same message (as long as the action wasn't "Delete from server")? Or, when a rule fires on a message, does PopTray cease at that point and no further rules get exercised against the message?

In other e-mail clients that provide rules or filters, you often get a stop-clause that you can add to rule. If a rule fires, whether or not any further rules also get exercised against the same message depends on whether or not the stop-clause was used. When a rule fires, if the stop-clause is omitted or disabled, execution continues to exercise the next rule(s) against the same message. When a rule fires, if the stop-clause is present or enabled, execution stops at that rule and no further rule(s) are excersized against the message.

By looking at a set of rules defined in PopTray, there is no way to really tell what rules get exercised against a particular message. Say I have a rule that looks for "#test" in the Subject header and marks that message as Spam (the only tag currently available within PopTray). Following that rule is another that deletes the message if it has "0-190-" anywhere within the body of the message. So I have:

rule 1 = mark as spam if "#test" is in the Subject
rule 2 = use tray color = red if "0-190-" is in the body.

I send myself a test e-mail that has "#test" in the Subject header and "0-190-" in the body. So which rules get exercised against it in PopTray? Rule 1 obviously should get exercised against the message and marks it as spam. Does that cease rule processing because rule 1 fired against the message? That means the e-mail gets marked as spam but never uses the tray color to notify me. Or do both rules get exercised against the message so it gets marked as spam and also uses the red tray color?

When a rule fires against a message, does PopTray cease processing the rules so no more get exercised against the same message? Or, after a rule fires on a message, does PopTray then move onto the next rule and start exercising it against the same message? Since there is no stop clause or stop option within the definition of a rule, I can't tell what will and will not get exercised against a particular message which means I really can't tell what will happen in PopTray.

User avatar
Rdsok
PopTray Family
Posts: 1422
Joined: Fri Mar 19, 2004 11:36 pm
Location: Norman, Oklahoma USA
Contact:

Post by Rdsok » Sun Jan 02, 2005 12:23 am

I think you'll find this to be of some help with rule precidence questions. viewtopic.php?t=1978&highlight=rule+order

Vanguard
Enthusiast
Posts: 40
Joined: Tue Oct 21, 2003 10:36 am

Post by Vanguard » Sun Jan 02, 2005 2:21 am

Rdsok wrote:I think you'll find this to be of some help with rule precidence questions. viewtopic.php?t=1978&highlight=rule+order
Which basically says that there is no way to stop processing rules (actually that discussion never discussed how rules amongst themselves handle execution order or how to stop processing other rules after one of them). They ALL get exercised against a message. That means they are effectively all OR'ed against the message. Rule 1 gets tested against the message, then rule 2, then rule 3, and on until the last rule. That means if a rule performs an action that obviates the actions by later rules that the it doesn't stop processing at that point.

Say rule 4 deletes the message from the server. Okay, so what would be the point on running any of the subsequent rules on that same message since obviously none of them will effect any change on the message. The message is gone, poof, so there's nothing else you can do on it. It would be stupid to run rule 4 that deletes the message only to try to run rule 5 that marks it as Spam. There's no message anymore to mark as spam!

The point on having a stop-clause or option in a rule is to short-circuit the rest of the OR'ing of the rules. In programming, there's no point in OR'ing out a dozen conditions if the first condition returns true or 1 since no values for any of the other conditions will change the result of the OR'ing. 1 OR anything is still 1. The same applies with rules. One rule may obviate the need for some or all subsequent rules. Any rules listed after a rule that deletes the message are superfluous. Do you then move all those rules so they are before the delete rule? Why waste processing time on rules that just waste time performing their actions when the result is the delete rule is going to get rid of the message, anyway?

I have a rule at the top of the rules list that checks for a passcode (aka magic string) in the Subject header. If I receive a passcoded message then I want to make sure NONE of the other rules are exercised against it. I don't want it deleted from the server by a subsequent rule that happens to match on its condition and I don't want a subsequent rule marking a passcode message as spam. Passcoding is supposed to bypass all filtering to ensure that message will be received and not modified, moved, tagged, or otherwise processed by any filters. I can't do that with PopTray. I'd like to define something similar to:

rule 1 = do nothing if Subject contains the "#pass" passcode, stop processing rules
rule 2 = mark as spam if Subject contains "#test"
rule 3 = delete from server if From contains "<myemailaddress>", stop processing rules

I send myself a test e-mail with both with a Subject of "checking rules #pass #test". The expected result is the message gets left in the Inbox and *no* other rules get exercised. But because PopTray doesn't provide a stop-clause, it runs rule 2 and then marks the message as spam. Passcoded messages are to bypass ALL further filtering so marking a passcoded message as spam is a wrong result. However, and again since PopTray doesn't have a stop-clause, rule 3 triggers because my e-mail address for the test e-mail was sent from me to me, and my supposedly passcoded message that I wanted to keep now gets deleted from the server. Again, I don't get the result expected.

Note that even if I change the order of these rules, the absence of the stop-clause makes it impossibe to end up with my test e-mail to not get deleted. In the reverse order of:

rule 1 = delete from server if From contains "<myemailaddress>", stop processing rules
rule 2 = mark as spam if Subject contains "#test"
rule 3 = do nothing if Subject contains the "#pass" passcode, stop processing rules

My test e-mail with Subject = "checking rules #test #pass" is sent from myself to myself so the first rule is going to delete the message. Even if rule 3 gets executed (but against what I don't know since the message is gone), it won't end up keeping the passcoded message.

It may impossible to define a decent rule set with PopTray if it has no means of short-circuiting the rules processing by allowing the use of a stop-clause. Order of execution *is* important, later rules may obviate or alter the effect of a prior rule, and changing order may still not achive the desired effect. Even the old and almost unsupported Magic Mail Monitor has an option to decide if a triggered rule stops processing further rules or not. With all the hoopla over having rows that can be all OR'ed or AND'ed for the conditions within a rule, I was damn surprised there was no stop-clause to also determine if that rule short-circuited the rest (to bypass them).

Imagine trying to program in C++ with the 'switch' statement but having no 'break' available to prevent executing the next case in the select. You normally would code.

Code: Select all

switch (n) {
    case 1:  cout << "value = one" << endl; 
             break;
    case 2:  cout << "value = two" << endl;
             break;
    case 3:  cout << "value = three" << endl;
             break;
    default: cout << "invalid number" << endl;
}
With values of 1, 2, and 3, you get just one line of output. However, without the 'break' statements, you get as many lines of output as there are for the matching case plus the number of remaining cases thereafter. With the 'break' statements, you get just one line of output. If, say, n = 1, you get:

value = one

Without the 'break' statements you'll get 1 to 4 lines of output. If, say, n = 1, and without the 'break' statements, you would get:

value = one
value = two
value = three
invalid number

Yeah, there are times when you would deliberately omit the 'break' statement within a case so it would also include the processing in the next case but often the omission of the 'break' is a mistake.

Without a stop-clause (i.e., break) for a rule, or an implied one where a rule that triggers then terminates processing of subsequent rules on that message, you get very little control over what happens and you may not get anything like what you expect.

User avatar
KY Dave
Not the Developer
Posts: 1599
Joined: Thu Mar 14, 2002 7:29 pm
Location: Burkesville, KY. U.S.A.
Contact:

Post by KY Dave » Sun Jan 02, 2005 4:49 am

Try using your PASSCODE rule to PROTECT the email. Then the DELETION rule won't function on it. I think, not sure, that if a rule PROTECTS an email, when it is MARKED AS SPAM, using the DELETE SPAM button won't delete the PROTECTED email.
KY Dave

Family Blog
You can STOP SPAM using PopFile and PopTray.

User avatar
Rdsok
PopTray Family
Posts: 1422
Joined: Fri Mar 19, 2004 11:36 pm
Location: Norman, Oklahoma USA
Contact:

Post by Rdsok » Sun Jan 02, 2005 6:19 am

KY Dave is correct, simply create a rule to protect an email with the passcode, it won't get deleted no matter what after that. You are trying to over-think it some. We all would love to see a stop processing feature also, but the currect implentation doesn't have that so you must work with what it there.

By simply knowing the precedence order you can create very good rules that do things you won't normally think of otherwise.

You can also do some cool things.. for instance make the the status of an email determine if you will delete it... I have several rules that will mark a message as spam, if they also are marked by my spam filter as spam with a [SPAM] tag then I tell it to delete them and I finally follow up all of my rules with one that if it is just marked with just the tag, I simply have Poptray mark it as spam so I can use the delete spam button after I have verified that is ok. I'm not sure that that will make sense.. but i can actually spell it out if you need me too with a set of rule descriptions.

Guest

Post by Guest » Sun Jan 02, 2005 6:27 pm

Unfortunately that means there is no way to prevent a passcoded message from possibly getting marked as spam.

rule 1: passcoded message
rule 2: mark as spam (detects header tag from anti-spam product)

or

rule 1: mark as spam (detects header tag from anti-spam product)
rule 2: passcoded message

In either order, it is possible the passcoded message will get marked as spam - but passcoding the message was supposed to bypass ALL further filtering. A passcoded message should NEVER get marked as spam regardless of the possibility of a false positive by rules or anti-spam products. That's a mandatory condition that I require of any e-mail client when processing my e-mails. Passcoding *bypasses* all further rules/filtering.

Boy, this sucks. I gave only one example. There are times after a rule fires that *no* other rules should ever be exercised against that same message. Another example would be color coding (although PopTray only lets me color the tray icon and not pick a color to highlight the message). I might have rule 1 use cyan on a message exceeding some byte size threshold (something else that is missing from PopTray) and rule 2 use purple on a message with some specific text in the Subject header. If rule 1 fires, it is irrelevant if rule 2 would've fired. I want to handle that huge e-mail differently than for other e-mails and I want the highlighting to identify that special handling is required. Changing their order could have other deliterious affects. You can't always get the effect you want by reording the rules when the result is that you fall through all the rules to exercise them all, anyway. In the switch code example that I showed, and with the absence of 'break' statements, there would be no way to prevent one case from interferring with another case unless it happened to the default case that was executed.

Rdsok's suggestion is something that I'm already aware of. That equates to using the switch code without breaks so multiple cases get exercised. Sometimes that is how you want the cases to work within a switch, but often you don't. In my situation, I *NEVER* want a passcoded message marked as spam. If anyone sends me a passcoded message, no other filters should ever get exercised against it. The spammers won't know the passcode but a couple of my good sender will, and I never want my rules or anti-spam product to falsely trigger on their message to get it marked as spam.

Guess I'll have to go back to using Magic for my e-mail monitor. The addition of rows in the rules (where you can OR or AND them all) lets me define better rules than the 2-condition rules of Magic, but the lack of control in their execution order prettymuch forces me back to Magic. PopTray was the first e-mail client (that I've used) that didn't let me manage execution order (with short-circuiting via a stop-clause). All of them have the same "feature" as PopTray of falling through the rules to exercise multiple rules against a message. Permitting more than one condition per rule is what lured me back to tryout PopTray again but lack of control in execution order pushed me away again. Missed it by thaaat much.

Thanks for the info, guys.

User avatar
KY Dave
Not the Developer
Posts: 1599
Joined: Thu Mar 14, 2002 7:29 pm
Location: Burkesville, KY. U.S.A.
Contact:

Post by KY Dave » Sun Jan 02, 2005 7:11 pm

It would seem that you could still use your rules to do what you want fairly simply.

What ever the criteria was for your rules, simply add a line that looks for your passcode and then check the box for NOT, also the criteria would need to be ALL. If your sorting program marks it as SPAM that satisfies one CRITERIA of the RULE, but if it has the PASSCODE then the other criteria isn't satisfied so the rule would not mark it as SPAM.

This could be added to any of the rules you don't want to fire on PASSCODE messages.

You might have to separate a few of your rules but it will function as you described.
KY Dave

Family Blog
You can STOP SPAM using PopFile and PopTray.

User avatar
lemming
Groupie
Posts: 55
Joined: Sun Jan 09, 2005 3:51 am
Location: Malaysia

Stop clause avail in future version

Post by lemming » Sun Jan 23, 2005 10:55 am

I'd have to agree with "guest" on this issue.

There should definitely be a stop clause for rules, i.e. "stop processing further if this rule is true".

As an example, some of my spam is caught early by simple rules, e.g. "vicodin" or "viagra" in the subject, but it continues to be processed by all rules that follow.

That seems to be a waste of processor time, plus it may slow things down if you have a lot of mail and/or many rules.

Dave et al have suggest workarounds, but they would break any rules that use the Needed->ANY Row option (which is actually the Boolean "Or" operator).
That is because the suggested changes require the Needed->ALL Rows option (the Boolean "And" operator), and Poptray currently does not allow you to combine row options.

I suppose you could combine some of the rows using regular expressions because they have their own "Or" operator (the | symbol), but that is an unnecessarily complex workaround.

Anyway, I did ask for a stop clause in the feature request section, and in response Renier wrote,
Renier wrote:This has been requested enough to be included in a future release.
So there ya go.

-Lemming.

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests