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
- Working Group Last Call: draft-ietf-sieve-spamtes… Alexey Melnikov
- Re: Working Group Last Call: draft-ietf-sieve-spa… Alexey Melnikov
- Re: Working Group Last Call: draft-ietf-sieve-spa… Ned Freed