One assumption that seems to be lurking behind this discussion is that the
principle function of Sieve is as an anti-spam mechanism and that this is
reinforced by the existance of the spamtest extension. A few additional points
need to be made about this:
(o) Sieve is a general purpose mechanism; it is not solely a tool for
blocking spam.
(o) Indeed as regards individual user Sieves, unless some external
spam-analyzer verdicts are made accessible via "spamtest", I tend to be
unenthusiastic about attempts by individual users to use Sieve to block
spam: individual Sieve attempts to personally detect spam tend to be
inefficient at best (each user having to reimplement the same checks),
and fairly ineffective compared to making some general spam-analyzer
result (that one hopes is consolidating lots more knowledge of spam
than individual users are likely to keep up-to-date) available via
"spamtest".
On the other hand, if some spam-analyzer results are accessible via
"spamtest", then having individual user Sieves check with "spamtest"
is fine -- but under such circumstances it may also be reasonable to
have a site policy that decides to unconditionally reject spam, and
not let users even have a choice of accepting spam! And if the
decision is indeed being made and configured at such a higher
group/MTA/site level, rather than in individual user Sieves, then the
user deployment argument -- that it is too hard to expect users to
update their Sieves (but these are the same user Sieves they're
supposedly keeping "up to date" on detecting spam?) to use a new form
of rejection -- doesn't convince me.
So the whole argument that Sieve needs to automatically, always reject
at SMTP level so that the specific case of spam rejection by individual
users will work better never did convince me. The
individual-users-rejecting-spam case is not the only use case for Sieve,
and not even always an especially appropriate use case for Sieve.
Sieve, and in particular Sieve protocol level rejection, is not "the
answer" to the spam problem. Which is not to say that Sieve protocol
level rejection isn't a very useful and desirable tool -- it certainly
is. But a sense of proportion is in order. And this gets to the next
issue:
(o) As has been discussed on the list before, and as others have pointed out
in responses, there are cases where protocol level rejection is not
feasible, and this lack of feasibility is not due to us all wanting to
emit spam blow-back, but rather due to fundamental characteristics of
SMTP (multiple recipients but lack of recipient-specific responses,
ASCII-only rejection text required), etc. Those issues don't go away
by us wishing they did in Sieve; unless and until those issues are
addressed via SMTP protocol changes, Sieve has to work with SMTP
as-it-is.
Regards,
Kristin