6.3 Triggers

Triggers are conditional statements that use the value of the `Subject' header to alter the control flow. Syntactically, a trigger is:

trigger [flags] pattern action-list done

Here, pattern is the pattern against which the `Subject' header is checked, flags are optional flags controlling the type of regular expression used (see section 6.5 Regular Expressions). For backward compatibility, the keyword rule may be used instead of trigger.

The triggers act as follows: First, the value of the `Subject' header is matched against the pattern `@@'pattern. If it matches, then the matched part is removed from the `Subject', and the action-list is executed.

Basically, putting aside the possibility to use different flavors of regular expressions, a trigger is equivalent to the following statement:

if header[Subject] :posix "(.*)@@pattern" modify header [Subject] "\1" action-list fi

Thus, adding the `@@rule-name' code to the `Subject' header of your message, triggers a rule named rule-name, specified in a user configuration file. For example:

---BEGIN RULE--- trigger :basic "^gpg-encrypt-john" gpg-encrypt "john's_gpg_key" done ---END---

Now you can simply send an email with the following subject: `hello John!@@gpg-encrypt-john' to process an outgoing message with the rule specified above--encrypt message with a John's public key. Moreover, the trigger will remove the `@@', so John will only receive a message with a subject `hello John!'.

Another example shows an even more dynamic trigger, that is using a substitution and back-references:

---BEGIN RULE--- trigger :extended "^gpg-encrypt:(.*)" gpg-encrypt "\1" add [X-GPG-Comment] "Encrypted for \1" done ---END---

To encrypt a message to user e.g. `John', simply send an email with a subject `hello John!@@gpg-encrypt:john's_gpg_key'. This way, you decide at a run time which public key should be used, without creating separate rules for each user; thanks to back-references, those 3--4 lines are enough.