Subject: Determinging consensus on reject

From: Cyrus Daboo <[email-masked]>
Date: Thu, 07 Dec 2006 10:10:44 -0500

Hi folks,
With my chair hat on:

The debate on reject seems to have died down but we need to make progress 
on this. Here is my reading of the consensus from this discussion:

1) As per discussions during IETF meeting, there is broad consensus for 
having two commands: "reject" and "ereject".

2) As per list discussions its clear that many implementers need to 
maintain the current "reject" behavior of allowing MDNs as they are useful 
in many cases, even though they appear to be harmful wrt spam blowback.

The proposal as defined by my reading of the consensus then is as follows:

1) Current "reject" command stays as-is. Server implementations MAY (at 
their discretion) use a protocol level reject if the reject text is only 
ASCII, but MUST use MDN when it contains non-ascii.

2) A new "ereject" command is introduced. This MUST do a protocol level 
reject. The text argument MAY contain non-ASCII text which MUST be suitably 
downgraded if the protocol level reject can only handle ASCII text.

The spec should also contain guidance on the use of each. In particular: 
"script generators SHOULD ensure that a rejection action being executed as 
a result of an anti-spam or anti-virus positive test be done using the 
ereject action". Also there should be guidance on "upgrading" existing 
scripts to use ereject instead of reject when appropriate as new sieve 
implementations are rolled out. There should also be a note about the fact 
that in some environments (e.g. MUAs) a protocol level reject cannot be 
done, in which case the ereject action will not be available, and reject 
will alsways end up doing MDNs, not matter what.

-- 
Cyrus Daboo