In the case where there's a conflict, what happens? Three possibilities:
* require implementations to reject any script they can't guarantee will
have problems (this is pretty hard)
* take the first/last action specified, and just get on with life
* run-time error, do a keep, then mail the user explaining what happened
I'd say do the actions in order and skip those actions which are illegal
by policy -- generating an email error report to the user for skipped
actions. That seems like the simplist way to do it.
What about the "obvious" cases, like allowing reject AND keep of the same
message? Should that be forbidden?
I think forbidding it is best but I could live with "pick one".
I'm okay with just making this policy, but having a logical order of
fallout would be useful. (Can't reject if keep, so ignore the reject.
Use the first specified action.)
Hmm. Well, while it would be easy to implement a "first one wins" deal, I'm
not convinced it is a good idea.
I think we have three basic actions that are peers, more or less -- reject,
keep, and discard. You have to pick one of them; you cannot pick more than one.
You then have some add-ons which have combining rules. Reply can be used with
any of the basic actions. Forward can be used with keep or discard, but not
reject. (A condition where a rejection stating that the mail was not saved was
sent to the originator should be a reliable indicator that nobody actually
received the message on behalf of this particular recipient.)
I'm not at all sure about fileinto. I'm convinced it could only group with
keep, but how does it interact with keep? I'd say fileinto by itself means only
do the fileinto and skip normal delivery, but what about keep combined with
fileinto?
Other questions are how many replies are allowed (only 1, I think) and how many
fileintos are allowed (not sure)?
Ned