[Top] [All Lists]

Re: Strong Opposition due to spam backscatter. Re: Last Call: draft-ietf-sieve-refuse-reject-07 and -08 (Sieve Email Filtering: Reject and Extended Reject Extensions) to Proposed Standard

2008-09-12 17:14:36

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

    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

(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