[Top] [All Lists]


2000-09-11 17:10:33

   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.

<Prev in Thread] Current Thread [Next in Thread>