I'm chiming on on what Matthew said, but there isn't anything specific
in what he said that I want to quote. So I'm just talking here....
Here's more detail about what I think happened in SD with respect to
refuse/reject:
* Chris brought up a situation in which there's an existing customer
base that uses the existing function and expects it to send MDNs with
non-ASCII text (Japanese, specifically, in Chris's case). It is
important to Chris that those existing customers not be surprised by a
changed spec and curtailed function. This is important enough that Sun
will likely ignore the standard if the standard changes the existing
function to behave differently in this regard.
* Everyone agreed that because of the abuse of MDNs/DSNs through spam,
protocol-level rejects are best when they can be used.
* Consensus -- as I recall it -- was to use two actions:
1. Leave the current action alone, but add text that says that
implementations MAY use protocol-level reject if and only if the
response text is US-ASCII.
2. Add a new action that ONLY accepts US-ASCII response text, and that
MUST use protocol-level reject.
* A script that uses the new action will know that it will never be
sending MDNs. A script that uses the old action will not be sure.
Therefore, we will encourage migration to the new action. The old
action, though, will remain for cases where the response text is
important to the script-writer, and where that response text might be in
a non-ASCII character set.
That's my memory of where we left it.
Like Matthew, I would like to VERY VERY STRONGLY DISCOURAGE the use of
Sieve scripts to generate MDNs. But I understand the situation Chris
describes, and I agree that we shouldn't pull this out from under
customers that expect it to work this way.
Let's provide this migration path, and hope that some day we can
deprecate the MDN-ful version. But that day will have to wait for a
while....
Barry
--
Barry Leiba, Internet Messaging Technology
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam