Date: Fri, 29 Jan 1999 13:48:54 -0500
From: Tony Hansen <tony(_at_)att(_dot_)com>
I personally think that adding this distinction NOW will vastly simplify
future additions to the language. I can think of several possible
extensions which definitely should not affect the delivery decisions
that are made elsewhere within the script. By saying that these new
actions must affect the delivery status without having a way of saying
that they don't, or having a model for such actions in the future, we
are going to make life more difficult in the future.
I agree with the distinction between actions that affect delivery
status and actions that do not.
I think part of the distinction should be:
Actions that do not affect delivery status can be used multiple times
and in any combination with each other. In the base draft, this
actions are "fileinto" and "redirect". Site policy may limit the
number of particular actions taken.
Only one action that affects delivery status may be taken. An attempt
to run more than one such action leads to a run-time error, which has
undefined behavior. In the base draft, these actions are "keep",
"discard", and "reject".
---
We can also nail down what happens when multiple delivery actions are
taken. First? Last? I dunno.
This allows a script to execute the actions that don't affect delivery
status immediately without queuing them up, but should allow
implementations that wish to detect conflicting actions. Future
extensions would have to be careful to maintain this balance.
Once concern that this raises is that I was intending to outlaw doing
a "reject" and a "fileinto", since this gives the sender the false
impression that a copy of the message was not kept. Should we be
concerned about this?
Larry