All actions described in this specification (setflag, addflag, removeflag,
mark, unmark) operate on an internal variable that contains the set of
[IMAP] flags
associated with the message being delivered. When the interpreter
starts executing
a script this variable contains an empty set. The 'addflag' action
adds flags
to the existing set. The 'removeflag' action removes flags from the
existing set.
The 'setflag' action replaces the existing set of flags with a new set.
Whenever the interpreter encounters a 'fileinto' or 'keep' action it files
the message with the current set of flags.
I'm not comfortable with the specification of an internal variable.
I'd prefer that the draft stick to the semantics of the operations. As I
see it, the actions added by this extension modify IMAP flags on the
message being processed. If the message is eventually kept or filed, the
flags go with it. If the message is deleted, the flags are meaningless.
'setflags' undoes any previous flag actions and causes the specified flags
to be set.
'addflag' sets the specified flags.
'removeflag' cancels the specified flags from being set.
Also, I think the descriptions of 'mark' and 'unmark' are unclear. They
should specify exactly what is to happen, and not have so many MAY do this
or that statements.
I like the idea of setting flags independently of 'fileinto' or
'keep'. I'd really much rather not have 'fileinto'/'keep' be a way of
setting flags.
I think the wording on 'reject' is too strong. What's wrong with making it
a no-op to set flags on a message which is then rejected or discarded? A
script editor can always warn "this has no effect" to the user, but that's
its business.