Re: Valid Flags before nested block {}

|         More questions for my Lint parser...What are the valid flags
|         before the nested block, my first guess is that only H and B
|         are meaningfull and possibly a lockfile.

H, B, A, a, E, e, and D affect the conditions and thus are meaningful when
the action is to open a brace.  H, B, and D would be meaningless, of course,
on any unconditional recipe, but they should not cause error messages.

Generally, flags that affect actions are invalid there, and b, h, f, i, and
r always are, but the others are partial exceptions: if you are using c to
launch a clone, then w, W, and a local lockfile can be meaningful.  If there
is no c, then w, W, and a local lockfile are invalid at the opening of a
braced block.

|         Right? Also is there anything that would concern the lockfile?
|         Should it be used at all?

A local lockfile can be used to lock a clone; the parent procmail will remove
it when the clone exits (thus it serves as a global lockfile for the clone). 
If the braced block does not launch a clone, asking for a local lockfile
generates an error.

|         I'm also bit uncertain when to use a over A and e over E,
|         would someone give clear examples. (Can the use of a over A
|         be checked by the Lint somehow: any rules?)

I don't reliably understand the question: what do you mean by "over"?
A, a, E, and e are mutually exclusive and no more than one should ever
appear on a single recipe.

A = try this recipe if the conditions succeeded on the most recent recipe at
    that nesting level that did not itself have an A nor an a

a = same as A, but moreover the action must have succeeded on the most
    recently tried recipe at that nesting level

e = same as A, but moreover the action must have failed on the most recently
    tried recipe at that nesting level; within the A universe, e is the op-
    posite of a

E = try this recipe if the conditions have failed on the most recent recipe
    at that nesting level that did not have an E and on since then every 
    recipe at that level that did have an E; essentially opposite of A

These mnemonics might help:

A: if you did the recipe at the start of the chain, try this one _A_lso
a: if the last action at that nesting level was _a_ccomplished
e: if the last action at that nesting level _e_rred
E: _E_lse because the conditions down the chain so far have not matched

How they interact with one another when used consecutively has not been
fully tested to my knowledge.  Consider this:

 :0
 * conditons
 non-delivering action1
 :0a
 action2
 :0e
 action3

Is action3 done if action2 failed or if action1 failed (or perhaps in
both situations)?  If the answer is action2, does this work to get action3
done if action1 failed?  I think it does, but does it also run action3 if
the conditions didn't match on the first recipe?

 :0
 * conditions
 non-delivering action1
 :0a
 action2
 :0E
 action3

I know what this structure does because I use it:

   :0
   * conditions
   non-delivering action1
   :0A
   action2
   :0E
   non-delivering action3
   :0A
   action 4

If the conditions match, action1 and action2 are performed and action4 is
not (of course action3 is not either), even if action2 is non-delivering; if
they fail, action3 and action4 are performed.  The A on the fourth recipe
refers back to the third and no farther.  But I don't know about this:

   :0
   * conditions
   non-delivering action1
   :0A
   * more conditions
   action2
   :0E
   non-delivering action3
   :0A
   action 4

Now, suppose the conditions on the first recipe match but those on the second
recipe do not match.  Would the third recipe (and thus the fourth one) be
attempted?  I would expect so.  If that isn't what you want, you can prevent
it this way:

   :0
   * conditions
   {
    :0
    non-delivering action 1

    :0
    * more conditions
    action2
   }
   :0E # ignores mismatch inside braces, looks only at same level
   non-delivering action3
   :0A
   action4

If that *is* what you want, you can be positive this way:

# if action2 is non-delivering or vulnerable to error that would cause
# fall-through
  DID2
  :0
  * conditions
  non-delivering action1
  :0A
  * more conditions
  {
   DID2=yes

   :0
   action2
  }

  :0
  * ! DID2 ?? .
  non-delivering action3
  :0A
  action4

# if action2 is delivering and sure to succeed
  :0
  * conditions
  non-delivering action1
  :0A
  * more conditions
  action2

  :0
  non-delivering action3
  :0A
  action4