I'm unhappy with the current draft.
There is reluctance to change the current behaviour for what was
presented as nothing more than an unwillingness to explain what we all
agreed were net good reasons for the change to a customer! The push to
change the draft in a way that (unlike the versions I worked on - i.e.
from pre-00 to Change log entry 07) makes it significantly fail to
address the blowback issue that was my primary motivation for getting
involved is not an improvement; it changes a view that had on-list
consensus for a long time, through many revision changes.
My last long post to the list to draw out views on this issue in order
to move forward was answered by the blocker, Ned, IIRC.
I just reread the "Spam blowback from Sieve implementations." thread to
refresh my memory. I reread Ned's posts, which made it explicit that
he had no intention of directly responding to the question I posed to
him, but his view is clear. Ned's answer to my question below is (an
implicit but clear) yes:
Do we want to have the spec allow implementers to not bother to
implement the ability to do proper smtp-time refusals, even though all
implementers at the meeting indicated that it was possible for the
implementations to be changed so that they could do so, and not doing so
produces and will continue to produce immense economic harm caused by
spam blowback?
We've discussed the issue pretty throughly in that thread and though Ned
and others have made notable points, we still disagree, or at least my
opinion remains the same. My answer, after balancing the pros and cons,
is still no.
I strongly support requiring a change to the default behaviour, and most
certainly requiring that all implementations implement the ability to do
proper smtp-time (or lmtp-time) protocol-level refusals (other than
MUA-based implementations). It's an important interoperability issue.
Given the current draft, the latter requires a small change:
To the sentence that begins:
"The Sieve interpreter MUST carry out one of the following actions
(listed in order from most to least preferred),"
add something like:
"MUST support the user's choice to carry out the most preferable action
possible"
An alternate (perhaps clearer) way of accomplishing this would be to
require that all (but MUA-based) implementations supporting 'reject'
also support 'ereject': change
" The ereject action MUST NOT be available in environments that do not
support protocol level rejection, e.g. an MUA."
to
" The ereject action MUST NOT be available in environments that do not
support protocol level rejection, e.g. an MUA, but MUST be available
in all other environments that support the reject action"