Re: [sieve] Sieve deleteheader and :count match type

Ken Murchison <murch@andrew.cmu.edu> Tue, 17 January 2017 12:13 UTC

Return-Path: <murch@andrew.cmu.edu>
X-Original-To: sieve@ietfa.amsl.com
Delivered-To: sieve@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEAE129447 for <sieve@ietfa.amsl.com>; Tue, 17 Jan 2017 04:13:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.399
X-Spam-Level:
X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms0ejHG0Ahu7 for <sieve@ietfa.amsl.com>; Tue, 17 Jan 2017 04:13:29 -0800 (PST)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBC61293E9 for <sieve@ietf.org>; Tue, 17 Jan 2017 04:13:29 -0800 (PST)
Received: from [172.31.24.61] (VPN-172-31-24-61.VPN.CMU.LOCAL [172.31.24.61]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v0HCDRSJ011494 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Jan 2017 07:13:27 -0500
To: Ned Freed <ned.freed@mrochek.com>
References: <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> <01Q9RHX13ZFM00004H@mauve.mrochek.com>
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
Message-ID: <3e737ff8-d3b3-3435-7602-b8d8e4cd8bde@andrew.cmu.edu>
Date: Tue, 17 Jan 2017 07:13:26 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <01Q9RHX13ZFM00004H@mauve.mrochek.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.17.120315
X-SMTP-Spam-Clean: 8% ( HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, MULTIPLE_REAL_RCPTS 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CC_NAME 0, __CC_NAME_DIFF_FROM_ACC 0, __CC_REAL_NAMES 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0)
X-SMTP-Spam-Score: 8%
X-Scanned-By: MIMEDefang 2.78 on 128.2.105.202
Archived-At: <https://mailarchive.ietf.org/arch/msg/sieve/ByekgC9uSI1BKKh4eyTXACaLoTU>
Cc: Sieve mailing list <sieve@ietf.org>
Subject: Re: [sieve] Sieve deleteheader and :count match type
X-BeenThere: sieve@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIEVE Working Group <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sieve/>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2017 12:13:31 -0000

Hi Ned,


On 01/16/2017 09:11 PM, Ned Freed wrote:
>> Does :index still behave in the same way with the :count match-type that
>> it does with :value, :is, :regex, etc?
>
> That depends on the context. :index is associated with multiple 
> extensions;
> its meaning depends on which one you're talking about.
>
> For example, the index extension only specifies how :index works with the
> header, address, and date tests. Note that these are tests, not 
> actions, and
> the interpretation of the combination of :index and :count is pretty 
> clear
> given the "number of specified entities" language in RFC 5231 section 
> 4.2:
> :index restricts the test to Nth field, adding :count to that 
> basically then
> gives you a 1 or 0 depending on whether or not there is an Nth field, 
> which is
> what is tested. (And in the case of the date test, it's further 
> restricted to
> fields containing valid dates.)
>
> In other words, these two tests are basically equivalent:
>
>   header :index 4 :count "gt" :comparator "i;ascii-numeric" "foo" "0"
>
>   header :index 4 :matches "foo" "*"
>
> Personally, I think the second test is much clearer, but YMMV.
>
> The :index that's part of deleteheader action isn't part of the index
> extension, but works pretty much the same way: It restricts the entire
> operation to the Nth field. And in this case the specification is very 
> clear
> (secion 5, fourth paragraph) that the <value-patterns> check, which would
> necessarily include :count, happens *after* the :index restriction is 
> applied.
>
> And this means that
>
>   deleteheader :index 2 :count "ge" :comparator "i;ascii-numeric" 
> "X-foo" [ "3" ]
>
> is a no-op, because the :index restriction is applied first, and means 
> that the
> number of fields under consideration is either 0 or 1, and can be >=3. 
> And that
> makes the addition of :count to :index useless in this context.
>
> But more generally, the :count match type really only makes sense in the
> context of tests or actions on at most one thing. It sort of falls 
> apart in the
> context of action that's acting on multiple things, because it makes 
> sense to
> apply the test part of an action on a case by case basis to the set of
> things the action is being applied to, and use that result to control 
> whether
> or not to apply the action.
>
> But the semantics of :count are "count the number of things and then test
> that". And while that plays fairly nicely with tests, it's really at odds
> with action semantics.
>
> More generally still, since :count is wierd, the accepted convention 
> is for new
> actions and tests to specify how :count works for them. RFC 5260 does 
> this for
> both currentdate and date. RFC 5703 explains how :count and :mime 
> interact. And
> so on.
>
> But editheader didn't do that for deleteheader, and that IMO means the 
> behavior
> of :count in the context of deleteheader is undefined unless :index is 
> also
> present, in which case it's useless.
>
> I also don't think that saying that :count tests perform a preliminary 
> count
> like :index :last is especially useful - can you think of a case where 
> you'd
> want to delete all headers of a given type based on how many of them are
> present? I can't.

No I can't, which is why I started thinking about the semantics of 
:count with deleteheader.  I'm fine making it a no-op or a syntax error.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University