Quote:
Originally Posted by xyzzy
...What in your actual rules for those examples spawned the jmapquery I see in your code? I don't see that. It's the matching criteria that you show as subject:file that's confusing me.
|
The rule I created in the rules user interface specified the following condition:
Quote:
If all of the following conditions apply
(1) Subject file
|
So "file" is the string which is used to search the subject field. I can't find any documentation so far on the
jmapquery sieve extension, but this is what I imagine is happening. See
RFC5228 in section 2.4.2. Strings.
Quote:
|
For entering larger amounts of text, such as an email message, a multi-line form is allowed. It starts with the keyword "text:", followed by a CRLF, and ends with the sequence of a CRLF, a single period, and another CRLF. The CRLF before the final period is considered part of the value.
|
In my
Rule File #1 section of the sieve code, the
allof test has two arguments:
- not string :is "$(stop)" "Y"
- jmapquery text: { "subject" : "file" }
So that
allof test will be satisfied if both the value of the (stop) variable is not "Y"
AND the result of the jmapquery search for the string "file" in the header "subject" is true. If satisfied, the
allof test actions which are performed are:
- The message is flagged.
- The value of the variable "L0_Test" is set to "Y".
- The value of the variable "skipinbox" is set to "Y".
Then in the
### 4d. Do rule actions section of the sieve script, the L0_Test variable value will cause the "hasmailbox" variable value to be set to "Y" and the message will be copied into the
Test folder. A bit later in the script, the "skipinbox" and "hasmailbox" variables will cause the implicit keep copy of the message to be discarded, so that it won't be filed into the Inbox.
I now wish I had used a different search string other than "file" for my example, since it could accidentally be interpreted as some filing operation rather than the subject search string.
Bill