Re: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt

Ned Freed <ned.freed@mrochek.com> Thu, 01 September 2005 17:12 UTC

Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81HCAkK055108; Thu, 1 Sep 2005 10:12:10 -0700 (PDT) (envelope-from owner-ietf-mta-filters@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81HCAuH055106; Thu, 1 Sep 2005 10:12:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f
Received: from mauve.mrochek.com (mauve.mrochek.com [209.55.107.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81HC8Tx055100 for <ietf-mta-filters@imc.org>; Thu, 1 Sep 2005 10:12:08 -0700 (PDT) (envelope-from ned.freed@mrochek.com)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LSIHHTC6JK006FCJ@mauve.mrochek.com> (original mail from ned.freed@mrochek.com) for ietf-mta-filters@imc.org; Thu, 1 Sep 2005 10:12:04 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1125594724; h=Date: From:Subject:MIME-version:Content-type; b=InOYFOba6N1xXvDqot0+GEmzr TwTMIBFbbMaHOwILisK49NuMa3apX75Fk7GGKRWJY9joAUWdi83Q2CA22y8TQ==
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LSICOJPSM8000092@mauve.mrochek.com>; Thu, 01 Sep 2005 10:12:01 -0700 (PDT)
Cc: MTA filtering mailing list <ietf-mta-filters@imc.org>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Message-id: <01LSIHHSIJG0000092@mauve.mrochek.com>
Date: Thu, 01 Sep 2005 09:45:49 -0700
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: Working Group Last Call: draft-ietf-sieve-spamtestbis-01.txt
In-reply-to: "Your message dated Thu, 01 Sep 2005 16:10:16 +0100" <431719D8.7010800@isode.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format="flowed"
References: <430070BC.2000604@isode.com> <431719D8.7010800@isode.com>
Sender: owner-ietf-mta-filters@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-mta-filters/mail-archive/>
List-ID: <ietf-mta-filters.imc.org>
List-Unsubscribe: <mailto:ietf-mta-filters-request@imc.org?body=unsubscribe>


> Alexey Melnikov wrote:

> > I would like to draw your attention to the following draft:
> >
> > <http://www.ietf.org/internet-drafts/draft-ietf-sieve-spamtestbis-01.txt>
> >
> > A two week working group last call of this document starts today on
> > August 15th 2005 and ends on Monday, August 29th 2005 at 6 pm EST.

> Hi folks,
> The WGLC has ended. I've sent 2 editorial corrections directly to the
> author.
> I've seen no comments on the mailing list, however I can't interpret
> that that the document is just perfect and can be sent to IESG.
> So can I please ask people who have reviewed the document to send me a
> short note saying that the document is Ok. I suggest that you volunteer,
> or I will start picking some victims!

I just reviewed the draft. A few comments...

First and most important, the specification fails to state what value is
checked by spamtest :percent when no spam test has been done. There are
basically four possibilities:

(1) Return an error. This has the effect of requiring robust scripts to
    perform a spamtest :value "eq" :comparator "i;ascii-numeric" "0"
    prior to doing a spamtest :percent. I don't think this is a good
    idea.

(2) Return 0, which of course conflates no test with test and found to
    be clear.

(3) Return an out of range value like "" or "-1" or "<untested>" or whatever.

(4) State that implementations are free to return whatever they want in this
    case. This more or less reduces to (1).

I think either (2) or (3) is the right choice.

Having the specification be silent on this issue is not good since people
will code their scripts to whatever behavior they see locally.

The document states that require ["spamtest", "spamtestplus"] SHOULD NOT be
done. It is hard to see how the use of requirements language can be usefully
applied to script construction. An implementation has to accept this and most
implementations have no way of warning about problematic usage (nor do I think
generating a warning would be appropriate in this case).

It would be better to say something like "In the interests of brevity and
clarity, scripts should specify either spamtestplus or spamtest in their
require clause, but not both".

It would also be good to reword the "MUST NOT use spamtest :percent without
require spamtestplus" as a sieve implementation requirement rather than a
script coding requirement. Maybe something like "sieve implementations MUST
return an error if :percent is used and spamtestplus is not specified".

Finally, the first and second parts of the security considerations, although
identical to RFC 3685, could use some clarification. THe first part currently
says:

   SIEVE implementations SHOULD ensure that "spamtest" and "virustest"
   tests can only occur for messages that have gone through a legitimate
   spam or virus check process.  If such checks rely on the addition of
   special headers to messages, it is the responsibility of the
   implementation to ensure that such headers cannot be spoofed by the
   sender, to prevent the implementation from being tricked into
   returning the wrong result for the test.

How can an implementation possibly control when scripts perform certain tests?
The intent, I think, is to say that the tests should only return an indication
that a test has been done when a legitimate test really has been done. So how
about:

   SIEVE implementations SHOULD ensure that "spamtest" and "virustest"
   tests only report spam and virus test results for messages that actually
   have gone through a legitimate spam or virus check process.  In particular,
   if such checks rely on the addition and subsequent checking of private
   header fields, it is the responsibility of the implementation to ensure
   that such headers cannot be spoofed by the sender or intermediary and
   thereby prevent the implementation from being tricked into returning the
   wrong result for the test.

The second part says:

   Server administrators MUST ensure that the virus checking tools are
   kept up to date, to provide reasonable protection for users using the
   "virustest" test.  Users should be made aware of the fact that the
   "virustest" test does not provide a 100% reliable way to remove all
   viruses, and they should continue to exercise caution when dealing
   with messages of unknown content and origin.

This is a fine bit of motherhood and apple pie, but the use of MUST here is
inappropriate IMO since the behavior of server admins has little if anything to
do with sieve implementation compliaance.

That's it!

				Ned