From nobody Sat Jan 14 05:19:05 2017 Return-Path: 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 D5771129B32 for ; Sat, 14 Jan 2017 05:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 P1BwUw2mdyGz for ; Sat, 14 Jan 2017 05:19:02 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.38]) (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 4C482129B1C for ; Sat, 14 Jan 2017 05:19:01 -0800 (PST) Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v0EDIxCL126539 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 14 Jan 2017 08:19:00 -0500 To: Sieve mailing list From: Ken Murchison Organization: Carnegie Mellon University Message-ID: Date: Sat, 14 Jan 2017 08:18:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.14.131217 X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODYTEXTP_SIZE_400_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_200_299 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, SMALL_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 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, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_IN_SUBJECT 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: 33% X-Scanned-By: MIMEDefang 2.78 on 128.2.157.38 Archived-At: Subject: [sieve] Sieve variables and editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 13:19:04 -0000 All, I'm in the process of implementing editheader in Cyrus IMAP and I'm wondering if variables are/should be allowed in header field names and/or values. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Sat Jan 14 06:13:47 2017 Return-Path: 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 6055B129B92 for ; Sat, 14 Jan 2017 06:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 i5hgndojEp_U for ; Sat, 14 Jan 2017 06:13:45 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2B87F129B7D for ; Sat, 14 Jan 2017 06:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1484403224; d=isode.com; s=june2016; i=@isode.com; bh=T7CX/F9YhCfs/Wv5b/qUytzdRWlu7e/RutBpJ46p7wg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gVvKCZ3jC2oUkm2rcv/dviIU1v94D4IgGdLrOEGetkduh+XX3vl3tjK98cwim2ClWiEtoy MgH+iZd928Fv0z4mI/RNm/SesAE2Kwc0SGsqKlg5vN7a7R+fx3Lzk5uYYYzwS2GmD72B3H j2B4KgZIa/xAxYl28hvzhwmgTR2mJK8=; Received: from [10.10.51.134] ((unknown) [85.255.236.133]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 14 Jan 2017 14:13:44 +0000 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: Date: Sat, 14 Jan 2017 14:23:13 +0000 Message-Id: <0F10022A-6EE1-4107-85B3-61E626899216@isode.com> References: To: Ken Murchison MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Sieve mailing list Subject: Re: [sieve] Sieve variables and editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 14:13:46 -0000 Hi Ken, > On 14 Jan 2017, at 13:18, Ken Murchison wrote: >=20 > All, >=20 > I'm in the process of implementing editheader in Cyrus IMAP and I'm wonder= ing if variables are/should be allowed in header field names and/or values. Yes, why not? Best Regards, Alexey= From nobody Sat Jan 14 09:48:11 2017 Return-Path: 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 CFDF8129C99 for ; Sat, 14 Jan 2017 09:48:09 -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 P-inHOTkavFX for ; Sat, 14 Jan 2017 09:48:08 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (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 59C03129C89 for ; Sat, 14 Jan 2017 09:48:08 -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 v0EHm5pu021073 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 14 Jan 2017 12:48:06 -0500 To: Alexey Melnikov References: <0F10022A-6EE1-4107-85B3-61E626899216@isode.com> From: Ken Murchison Organization: Carnegie Mellon University Message-ID: Date: Sat, 14 Jan 2017 12:48:05 -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: <0F10022A-6EE1-4107-85B3-61E626899216@isode.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.14.173917 X-SMTP-Spam-Clean: 8% ( HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_600_699 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_URI_HTTPS 0, REFERENCES 0, __ANY_URI 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, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 8% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.204 Archived-At: Cc: Sieve mailing list Subject: Re: [sieve] Sieve variables and editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 17:48:10 -0000 No reason against it, just asking. Should a redirect action use the original headers or the edited? I'm assuming that reject and vacation use the original headers. On 01/14/2017 09:23 AM, Alexey Melnikov wrote: > Hi Ken, > >> On 14 Jan 2017, at 13:18, Ken Murchison wrote: >> >> All, >> >> I'm in the process of implementing editheader in Cyrus IMAP and I'm wondering if variables are/should be allowed in header field names and/or values. > Yes, why not? > > Best Regards, > Alexey -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Sat Jan 14 11:56:23 2017 Return-Path: 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 5E69B129D58 for ; Sat, 14 Jan 2017 11:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Bzok7SWMIJQK for ; Sat, 14 Jan 2017 11:56:20 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 65758129421 for ; Sat, 14 Jan 2017 11:56:20 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9O979KBG0006055@mauve.mrochek.com> for sieve@ietf.org; Sat, 14 Jan 2017 11:51:18 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9M6R6SN00000066@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Sat, 14 Jan 2017 11:50:30 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9O96X15FY000066@mauve.mrochek.com> Date: Sat, 14 Jan 2017 11:41:04 -0800 (PST) In-reply-to: "Your message dated Sat, 14 Jan 2017 12:48:05 -0500" References: <0F10022A-6EE1-4107-85B3-61E626899216@isode.com> To: Ken Murchison Archived-At: Cc: Sieve mailing list Subject: Re: [sieve] Sieve variables and editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 19:56:21 -0000 > No reason against it, just asking. > Should a redirect action use the original headers or the edited? RFC 5293 section 7 second paragraph says it uses the modified header. The example at the end of section 4 won't work if the original header is used. > I'm assuming that reject and vacation use the original headers. Reject generates a DSN or MDN; the first paragraph of section 7 clearly states that the original header is used in such cases. A lot of vacation implementations don't include the original message in the response; in such cases the question is moot. For those implementations that do include the original message, the same paragraph also covers "similar disposition messages"; I'd say this sort of vacation response falls into that category. Ned From nobody Mon Jan 16 16:39:24 2017 Return-Path: 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 388511293F0 for ; Mon, 16 Jan 2017 16:39:23 -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 mnkPBYn31QPe for ; Mon, 16 Jan 2017 16:39:22 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.203]) (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 E8EA91295CD for ; Mon, 16 Jan 2017 16:39:21 -0800 (PST) Received: from localhost.localdomain (static-72-88-80-48.bflony.fios.verizon.net [72.88.80.48]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v0H0dDZw001820 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Jan 2017 19:39:19 -0500 To: Sieve mailing list From: Ken Murchison Message-ID: <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> Date: Mon, 16 Jan 2017 19:39:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.7.221517 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_400_499 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, RDNS_GENERIC_POOLED 0, RDNS_STATIC 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 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, __RDNS_STATIC_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_IN_SUBJECT 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: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.203 Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 00:39:23 -0000 Does :index still behave in the same way with the :count match-type that it does with :value, :is, :regex, etc? In other words, would the following delete the second instance of the X-foo header if, and only if, there are 3 or more instances? deleteheader :index 2 :count "ge" :comparator "i;ascii-numeric" "X-foo" [ "3" ] -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Mon Jan 16 19:34:50 2017 Return-Path: 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 DC857129490 for ; Mon, 16 Jan 2017 19:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Kf8DmAnOnEsS for ; Mon, 16 Jan 2017 19:34:46 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 7E20C129466 for ; Mon, 16 Jan 2017 19:34:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9RHX317JK0007FS@mauve.mrochek.com> for sieve@ietf.org; Mon, 16 Jan 2017 19:32:48 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Mon, 16 Jan 2017 19:32:45 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9RHX13ZFM00004H@mauve.mrochek.com> Date: Mon, 16 Jan 2017 18:11:29 -0800 (PST) In-reply-to: "Your message dated Mon, 16 Jan 2017 19:39:12 -0500" <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> References: <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> To: Ken Murchison Archived-At: Cc: Sieve mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 03:34:49 -0000 > 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 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. Ned From nobody Tue Jan 17 04:13:33 2017 Return-Path: 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 ; 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 ; 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 ; 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 References: <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> <01Q9RHX13ZFM00004H@mauve.mrochek.com> From: Ken Murchison 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: Cc: Sieve mailing list 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 From nobody Tue Jan 17 04:20:20 2017 Return-Path: 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 A0BEB129447 for ; Tue, 17 Jan 2017 04:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 qHO5sTGnSDG2 for ; Tue, 17 Jan 2017 04:20:17 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC471293E9 for ; Tue, 17 Jan 2017 04:20:17 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 55BF1FA0088; Tue, 17 Jan 2017 12:20:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1484655615; bh=qcmr+If0wVzVAHtWJHMV/IPFjfyHbuzeEoIDU6J1siA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=cFTlXyy4ysewFLrajdY3S/ltmfaspsgg4YRkJmTaVPI8+7OKPcqjAxD1JHHXwaPJG 25rzkRjvpA0SvW2RtDuHJqasa9Fk99whbRVENg4yvkRS0lUJR1eq6nQBnhL28RZFUm tPJ7t79WmvvgnMbBXRNOiSe6HnH32ITTASaV0hW0= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1484655613-5233-5230/11/41; Tue, 17 Jan 2017 12:20:13 +0000 From: Arnt Gulbrandsen To: sieve@ietf.org Date: Tue, 17 Jan 2017 12:20:13 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: <01Q9RHX13ZFM00004H@mauve.mrochek.com> References: <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> <01Q9RHX13ZFM00004H@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 12:20:19 -0000 NED+mta-filters@mauve.mrochek.com writes: > I also don't think that saying that :count tests perform a preliminary = count=20 > like :index :last is especially useful - can you think of a case where = you'd=20 > want to delete all headers of a given type based on how many of them = are=20 > present? I can't. It's far-fetched, but deleting both subject fields if there are two or=20 more? I think most people choose to use the first. Choosing to delete = both=20 isn't entirely unreasonable, though. The same applies to other header fields that may occur at most once. Arnt From nobody Tue Jan 17 07:31:44 2017 Return-Path: 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 C50B4129452 for ; Tue, 17 Jan 2017 07:31:43 -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 nprTLAmsqGbx for ; Tue, 17 Jan 2017 07:31:40 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.38]) (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 AD7B61294A9 for ; Tue, 17 Jan 2017 07:31:40 -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 v0HFVccV070726 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Jan 2017 10:31:39 -0500 To: sieve@ietf.org From: Ken Murchison Organization: Carnegie Mellon University Message-ID: <7357c8a0-4256-963c-3122-039053135f3b@andrew.cmu.edu> Date: Tue, 17 Jan 2017 10:31:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.17.152116 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_500_599 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 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, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.157.38 Archived-At: Subject: [sieve] Sieve :fcc option X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 15:31:43 -0000 All, A vendor that uses Cyrus IMAP has some customers that would like to have copies of outgoing Sieve-generated messages (e.g. reject, vacation) stored in their Sent mailbox. We could obviously do this with a user configurable option, but I was thinking of extending Sieve to support a :fcc option on reject, vacation and any new actions where it might apply. The option could also leverage draft-bosch-sieve-special-use to do something like :fcc "\\Sent" Thoughts? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Jan 17 08:50:38 2017 Return-Path: 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 621AD129594 for ; Tue, 17 Jan 2017 08:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 DFweOeuzCZOG for ; Tue, 17 Jan 2017 08:50:36 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 874CF1279EB for ; Tue, 17 Jan 2017 08:50:36 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9S9O35GFK000E6T@mauve.mrochek.com> for sieve@ietf.org; Tue, 17 Jan 2017 08:47:16 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Tue, 17 Jan 2017 08:47:14 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9S9O1X09A00004H@mauve.mrochek.com> Date: Tue, 17 Jan 2017 08:42:37 -0800 (PST) In-reply-to: "Your message dated Tue, 17 Jan 2017 10:31:38 -0500" <7357c8a0-4256-963c-3122-039053135f3b@andrew.cmu.edu> References: <7357c8a0-4256-963c-3122-039053135f3b@andrew.cmu.edu> To: Ken Murchison Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] Sieve :fcc option X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:50:37 -0000 > A vendor that uses Cyrus IMAP has some customers that would like to have > copies of outgoing Sieve-generated messages (e.g. reject, vacation) > stored in their Sent mailbox. We could obviously do this with a user > configurable option, but I was thinking of extending Sieve to support a > :fcc option on reject, vacation and any new actions where it > might apply. The option could also leverage > draft-bosch-sieve-special-use to do something like :fcc "\\Sent" I see no problem for notify or vacation, but there's a serious semantics issue with reject - when you reject a message you are saying, "I didn't receive" this message". If you implement an action where you do in fact receive the message, albeit as a part of a DSN, you're essentially lying about what you did. Accurate information about who actually received what is especially important in environments with compliance archiving requirements. I don't look forward to explaining how a reject ended up being a keep. Ned From nobody Tue Jan 17 08:50:41 2017 Return-Path: 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 C32591279EB for ; Tue, 17 Jan 2017 08:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 HVPEpGVcWzFo for ; Tue, 17 Jan 2017 08:50:37 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 EA99A129592 for ; Tue, 17 Jan 2017 08:50:36 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9S9R3JK4W000EBT@mauve.mrochek.com> for sieve@ietf.org; Tue, 17 Jan 2017 08:49:42 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Tue, 17 Jan 2017 08:49:39 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9S9R24CP800004H@mauve.mrochek.com> Date: Tue, 17 Jan 2017 08:47:39 -0800 (PST) In-reply-to: "Your message dated Tue, 17 Jan 2017 12:20:13 +0000" References: <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> <01Q9RHX13ZFM00004H@mauve.mrochek.com> To: Arnt Gulbrandsen Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:50:37 -0000 > NED+mta-filters@mauve.mrochek.com writes: > > 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. > It's far-fetched, but deleting both subject fields if there are two or > more? I think most people choose to use the first. Choosing to delete both > isn't entirely unreasonable, though. I don't really see a case for deleting all of them. Deleting all but one makes a certain amount of sense, but you can't do that directly with a single deleteheader action. > The same applies to other header fields that may occur at most once. Again, all but one, sure, or maybe appending them to each other. But not full deletion. Ned From nobody Tue Jan 17 10:17:34 2017 Return-Path: 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 BAB421293DA for ; Tue, 17 Jan 2017 10:17:33 -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 gU0D7tr2_kqQ for ; Tue, 17 Jan 2017 10:17:32 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.37]) (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 D47CF1293D8 for ; Tue, 17 Jan 2017 10:17:32 -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 v0HIHUiH003188 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Jan 2017 13:17:31 -0500 To: sieve@ietf.org References: <7357c8a0-4256-963c-3122-039053135f3b@andrew.cmu.edu> <01Q9S9O1X09A00004H@mauve.mrochek.com> From: Ken Murchison Organization: Carnegie Mellon University Message-ID: <228a6d0a-8e45-e2f7-5e3d-526bbbc388f3@andrew.cmu.edu> Date: Tue, 17 Jan 2017 13:17:30 -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: <01Q9S9O1X09A00004H@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.175717 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 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, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 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_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.157.37 Archived-At: Subject: Re: [sieve] Sieve :fcc option X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 18:17:34 -0000 On 01/17/2017 11:42 AM, Ned Freed wrote: >> A vendor that uses Cyrus IMAP has some customers that would like to have >> copies of outgoing Sieve-generated messages (e.g. reject, vacation) >> stored in their Sent mailbox. We could obviously do this with a user >> configurable option, but I was thinking of extending Sieve to support a >> :fcc option on reject, vacation and any new actions where it >> might apply. The option could also leverage >> draft-bosch-sieve-special-use to do something like :fcc "\\Sent" > > I see no problem for notify or vacation, but there's a serious > semantics issue > with reject - when you reject a message you are saying, "I didn't > receive" this > message". If you implement an action where you do in fact receive the > message, > albeit as a part of a DSN, you're essentially lying about what you did. > > Accurate information about who actually received what is especially > important > in environments with compliance archiving requirements. I don't look > forward to > explaining how a reject ended up being a keep. Ahh, good point. Thanks Ned. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Tue Jan 17 10:21:36 2017 Return-Path: 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 845C4129530 for ; Tue, 17 Jan 2017 10:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 cqZtTCRsJBdd for ; Tue, 17 Jan 2017 10:21:33 -0800 (PST) Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B194E127ABE for ; Tue, 17 Jan 2017 10:11:25 -0800 (PST) Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 46AD2FA0088; Tue, 17 Jan 2017 18:11:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1484676683; bh=an+BJUhKTG9+7012Gn8dD2bjM8orSIeYAZuATtgfyg8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=rxhMrBECMrn7u3t1yqfeSz8vcty/lgLPaJ0WyzclCIbyhuUFVlXtpJkybhvqZZqsd jowZqFCDQTon1EcOxAqi9+UXXJNpkn508Ux8pt0kJm6purHwvr0lq9vGp87/2Qc1UZ n/9u2YgNp3yYpXPZXSB0ycNY2PxvLD1lBB1xszgk= Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1484676682-5232-5230/11/50; Tue, 17 Jan 2017 18:11:22 +0000 From: Arnt Gulbrandsen To: sieve@ietf.org Date: Tue, 17 Jan 2017 18:11:22 +0000 User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Devuan GNU/Linux 1.0 (jessie) Mime-Version: 1.0 Message-Id: In-Reply-To: <01Q9S9R24CP800004H@mauve.mrochek.com> References: <82102421-fed0-13eb-f557-83c878618a04@andrew.cmu.edu> <01Q9RHX13ZFM00004H@mauve.mrochek.com> <01Q9S9R24CP800004H@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 18:21:34 -0000 Ned Freed writes: >> It's far-fetched, but deleting both subject fields if there are two or >> more? I think most people choose to use the first. Choosing to delete both >> isn't entirely unreasonable, though. > > I don't really see a case for deleting all of them. FWIW, the messages I saw with two subject fields (back when I cared about such things) had two misleading/garbage/bad subject fields, not one with a bad value and one with an appropriate value. My choice was to keep the shortest syntactically valid subject. But based on the data I saw I considered deleting both to be a defensible option. >> The same applies to other header fields that may occur at most once. > > Again, all but one, sure, or maybe appending them to each other. But not > full deletion. I see I also analysed messages with two content-type, content-transfer-encoding, message-id and date fields, but don't seem to have seen any where deleting both was appropriate. Arnt From nobody Tue Jan 17 14:17:42 2017 Return-Path: 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 6BF8D1294B2 for ; Tue, 17 Jan 2017 14:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=nwpvXlli; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ky7zEMZz 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 Iwyp_wiu1vqu for ; Tue, 17 Jan 2017 14:17:40 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461AB1294A1 for ; Tue, 17 Jan 2017 14:17:40 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 84C0C208F0 for ; Tue, 17 Jan 2017 17:17:39 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 17 Jan 2017 17:17:39 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=hwlMUUjzKizWH7nA5exwt0gnMVs=; b=nwpvXllicYIetebeo9OIa wGxlMnsSwLuF00ITbbvzSpdAVZjzxUxsbr+lC+FSqtmqnDQcYn5H4gFAfJpyHTrb g+czElbBkUioyLSEZtcXBMdSoJSFfdEYvQK8qAeqI5wIJlOkpcBtf/LKhAdnPDbz YzXr1bffD3Vg1IenzoOBr8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=smtpout; bh=hwlMUUjzKizWH7nA5exwt0gnM Vs=; b=ky7zEMZz6KYL6qRCrSUS/nvMN32vNTIps82w0RfzwPDYlI0dR+uXDNgas 5FDCYXp6aln3mxqyg+M3tZg+j6UOM/TtKftBWi4dDpnTjKstphkKllHGF1DOS5bF c+bNyOfuYZlg3qZlXY5SqKJGHxsjrRs6jpeuobjpfPNOHZqTHY= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 678C5BAB48; Tue, 17 Jan 2017 17:17:39 -0500 (EST) Message-Id: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> From: Bron Gondwana To: sieve@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fd047210 Date: Wed, 18 Jan 2017 09:17:39 +1100 Archived-At: Subject: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 22:17:41 -0000 I wasn't on the list until just now, but it's one of my users who requested :fcc or similar. > > A vendor that uses Cyrus IMAP has some customers that would like to have > > copies of outgoing Sieve-generated messages (e.g. reject, vacation) > > stored in their Sent mailbox. We could obviously do this with a user > > configurable option, but I was thinking of extending Sieve to support a > > :fcc option on reject, vacation and any new actions where it > > might apply. The option could also leverage > > draft-bosch-sieve-special-use to do something like :fcc "\\Sent" > I see no problem for notify or vacation, but there's a serious semantics issue > with reject - when you reject a message you are saying, "I didn't receive" this > message". If you implement an action where you do in fact receive the message, > albeit as a part of a DSN, you're essentially lying about what you did. > > Accurate information about who actually received what is especially important > in environments with compliance archiving requirements. I don't look forward to > explaining how a reject ended up being a keep. > > Ned So don't lie if you don't want to lie. I see things the other way around, if you want to reject something then you want to reject it, but you might also want to keep a copy of every email that's been sent out of the system on your behalf. If your environment has compliance archiving requirements, then don't let users do that. If you're not allowed to keep copies of reject emails, then don't keep a copy of them. It's quite possible to set up an environment where every email going out of the organisation gets archived completely independent of the sieve engine, in which case you'd still be keeping copies of outbound rejects. Not even allowing this in sieve doesn't change the fact that people might want to lie and not everybody has compliance archiving requirements. Bron. -- Bron Gondwana brong@fastmail.fm From nobody Tue Jan 17 15:17:17 2017 Return-Path: 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 85F57129516 for ; Tue, 17 Jan 2017 15:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 lTQeuBQo6N72 for ; Tue, 17 Jan 2017 15:17:14 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 5C530129444 for ; Tue, 17 Jan 2017 15:17:14 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9SN4BF98W000GGJ@mauve.mrochek.com> for sieve@ietf.org; Tue, 17 Jan 2017 15:12:11 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Tue, 17 Jan 2017 15:12:09 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9SN4A5CB400004H@mauve.mrochek.com> Date: Tue, 17 Jan 2017 15:04:23 -0800 (PST) In-reply-to: "Your message dated Wed, 18 Jan 2017 09:17:39 +1100" <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:17:15 -0000 > I wasn't on the list until just now, but it's one of my users who requested :fcc or similar. > > > A vendor that uses Cyrus IMAP has some customers that would like to have > > > copies of outgoing Sieve-generated messages (e.g. reject, vacation) > > > stored in their Sent mailbox. We could obviously do this with a user > > > configurable option, but I was thinking of extending Sieve to support a > > > :fcc option on reject, vacation and any new actions where it > > > might apply. The option could also leverage > > > draft-bosch-sieve-special-use to do something like :fcc "\\Sent" > > I see no problem for notify or vacation, but there's a serious semantics issue > > with reject - when you reject a message you are saying, "I didn't receive" this > > message". If you implement an action where you do in fact receive the message, > > albeit as a part of a DSN, you're essentially lying about what you did. > > > > Accurate information about who actually received what is especially important > > in environments with compliance archiving requirements. I don't look forward to > > explaining how a reject ended up being a keep. > > > > Ned > So don't lie if you don't want to lie. No, you don't lie because you care about user experience, not violating the least astonishment principle, etc. > I see things the other way around, if you want to > reject something then you want to reject it, but you might also want to keep a copy > of every email that's been sent out of the system on your behalf. Then keep a record of the rejection for the user, as opposed to keeping a copy of the message that was rejected. Indeed, if you're going to keep track of all rejections you have to allow for this in order to deal with rejections that occur before the message transferred. > If your environment has compliance archiving requirements, then don't let users do > that. If you're not allowed to keep copies of reject emails, then don't keep a copy of > them. > It's quite possible to set up an environment where every email going out of the organisation > gets archived completely independent of the sieve engine, in which case you'd still be keeping > copies of outbound rejects. Not even allowing this in sieve doesn't change the fact that people > might want to lie and not everybody has compliance archiving requirements. You're now conflating all sorts of different things: Informing users of rejections as opposed to revealing message content, outgoing rejections, which have absolutely nothing to do with the matter at hand, and retaining messages at the system level, which again has nothing to do with what's being proposed here. The issue here is simple: The :fcc mechanism on reject provides a way for your *users* to lie to other *users* and say that they haven't received a message when in fact they have. If you don't see how this can become extremely problematic, I'm afraid there's no point in further discussion. Ned From nobody Tue Jan 17 15:29:11 2017 Return-Path: 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 57087129516 for ; Tue, 17 Jan 2017 15:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=dlDZmqrG; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=a3Z107IM 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 jtdMnfLV5Wff for ; Tue, 17 Jan 2017 15:29:09 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6AF129445 for ; Tue, 17 Jan 2017 15:29:08 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6464520840; Tue, 17 Jan 2017 18:29:08 -0500 (EST) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Tue, 17 Jan 2017 18:29:08 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=2vO4OFRjUBHcn+FFgJmU9TpVhy s=; b=dlDZmqrGqryfBFHh3RdEyJkL21KGqRp4sLqSrlukQcExAtrxzxLM8a53f1 U1d4PgJvN4BPC92oku6pik+B5ep0wRiBzndEAzJh16f+L4NOzf+SF38H5wpNaz6/ +vbmEWEFFPFoAHEnkIA37uNEmUHrSjjGA2bTjoSow3XDou3jw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=2v O4OFRjUBHcn+FFgJmU9TpVhys=; b=a3Z107IMSwb03AB4eZsHaprw6b8mQa9wJ3 GXca0U7Oc3ON1+o0Q4692hydCTdrGTNsKKRRlT7aID5ZxnnjWZIQis0GoNdHaU5k D9m5ug8DiUG0g1F+EfFSM+THdJC9nTLNSMYgSYKWiGj8nOodPcEwS7J8J7/8N3t7 swcIAlmmo= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 40EE89EEF7; Tue, 17 Jan 2017 18:29:08 -0500 (EST) Message-Id: <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> From: Bron Gondwana To: Ned Freed MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fd047210 Date: Wed, 18 Jan 2017 10:29:08 +1100 In-Reply-To: <01Q9SN4A5CB400004H@mauve.mrochek.com> References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:29:10 -0000 On Wed, 18 Jan 2017, at 10:04, Ned Freed wrote: > > I wasn't on the list until just now, but it's one of my users who requested :fcc or similar. > > > > > A vendor that uses Cyrus IMAP has some customers that would like to have > > > > copies of outgoing Sieve-generated messages (e.g. reject, vacation) > > > > stored in their Sent mailbox. We could obviously do this with a user > > > > configurable option, but I was thinking of extending Sieve to support a > > > > :fcc option on reject, vacation and any new actions where it > > > > might apply. The option could also leverage > > > > draft-bosch-sieve-special-use to do something like :fcc "\\Sent" > > > > I see no problem for notify or vacation, but there's a serious semantics issue > > > with reject - when you reject a message you are saying, "I didn't receive" this > > > message". If you implement an action where you do in fact receive the message, > > > albeit as a part of a DSN, you're essentially lying about what you did. > > > > > > Accurate information about who actually received what is especially important > > > in environments with compliance archiving requirements. I don't look forward to > > > explaining how a reject ended up being a keep. > > > > > > Ned > > > So don't lie if you don't want to lie. > > No, you don't lie because you care about user experience, not violating > the least astonishment principle, etc. > > > I see things the other way around, if you want to > > reject something then you want to reject it, but you might also want to keep a copy > > of every email that's been sent out of the system on your behalf. > > Then keep a record of the rejection for the user, as opposed to keeping a copy > of the message that was rejected. Indeed, if you're going to keep track > of all rejections you have to allow for this in order to deal with > rejections that occur before the message transferred. OK, I see where the misunderstanding has come from. What I'm proposing is keeping a copy of the rejection. Basically the user wants a copy of every email sent on their behalf. > > If your environment has compliance archiving requirements, then don't let users do > > that. If you're not allowed to keep copies of reject emails, then don't keep a copy of > > them. > > > It's quite possible to set up an environment where every email going out of the organisation > > gets archived completely independent of the sieve engine, in which case you'd still be keeping > > copies of outbound rejects. Not even allowing this in sieve doesn't change the fact that people > > might want to lie and not everybody has compliance archiving requirements. > > You're now conflating all sorts of different things: Informing users of > rejections as opposed to revealing message content, outgoing rejections, which > have absolutely nothing to do with the matter at hand, and retaining messages > at the system level, which again has nothing to do with what's being > proposed here. > > The issue here is simple: The :fcc mechanism on reject provides a way for your > *users* to lie to other *users* and say that they haven't received a message > when in fact they have. If you don't see how this can become extremely > problematic, I'm afraid there's no point in further discussion. So as discovered above, we're talking past each other. I just want to keep a copy of the rejection that was sent out by sieve on the user's behalf. -- Bron Gondwana brong@fastmail.fm From nobody Tue Jan 17 16:12:31 2017 Return-Path: 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 DBCAD129408 for ; Tue, 17 Jan 2017 16:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 pkMrZkYczr1q for ; Tue, 17 Jan 2017 16:12:29 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 E337D127A90 for ; Tue, 17 Jan 2017 16:12:28 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9SP1T06Z4000JVS@mauve.mrochek.com> for sieve@ietf.org; Tue, 17 Jan 2017 16:07:26 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Tue, 17 Jan 2017 16:07:23 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9SP1R5AP200004H@mauve.mrochek.com> Date: Tue, 17 Jan 2017 15:43:47 -0800 (PST) In-reply-to: "Your message dated Wed, 18 Jan 2017 10:29:08 +1100" <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Cc: sieve@ietf.org, Ned Freed Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 00:12:30 -0000 > > Then keep a record of the rejection for the user, as opposed to keeping a copy > > of the message that was rejected. Indeed, if you're going to keep track > > of all rejections you have to allow for this in order to deal with > > rejections that occur before the message transferred. > OK, I see where the misunderstanding has come from. What I'm proposing is > keeping a copy of the rejection. Basically the user wants a copy of every email > sent on their behalf. When a Sieve ereject/reject occurs prior to delivery, and circumstances require the use of a message as opposed to an SMTP status code, use of a DSN is required. RFC 5429, section 2.1.2: In this case, the server MUST accept the message and generate DSNs for all recipients that are refusing it. And DSNs are effectively required to contain at least a portion of the rejected message. (There's an exception for DSNs generated by gateways to foreign mail systems, but it clearly doesn't apply here.) Like it or not, these DSNs are "messages sent on [the users] behalf", and they absolutely do contain part or all of the rejected message. > So as discovered above, we're talking past each other. I just want to keep a > copy of the rejection that was sent out by sieve on the user's behalf. And such messages can and often do contain part or all of the original message, creating exactly the issue I've been talking about. Ned From nobody Tue Jan 17 16:21:25 2017 Return-Path: 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 A2F3312940F for ; Tue, 17 Jan 2017 16:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=TRapOMkY; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=PBr1XK6u 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 1vXrqeU47Q8x for ; Tue, 17 Jan 2017 16:21:22 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5045F129408 for ; Tue, 17 Jan 2017 16:21:22 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BF8A3206EA; Tue, 17 Jan 2017 19:21:21 -0500 (EST) Received: from web4 ([10.202.2.214]) by compute6.internal (MEProxy); Tue, 17 Jan 2017 19:21:21 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=zjQoPSCc3zE8OXsaPiWCd5VA/H Y=; b=TRapOMkY2LpxG6TEM+PjXV8B07+aLv0Tlg2hrVq9TbIf7zzv4UUZKzoilb Y5HpJibBv+0hMjcpyjyUk4yVvYPqSDxNsY+mM9UJK6AglQacFA9EzmOkTmhYH6Fz sw0kc3KEEs3Ka4OcAF6//M67khF+yH59F8v8I41jpVoKRs9/M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=zj QoPSCc3zE8OXsaPiWCd5VA/HY=; b=PBr1XK6uf9/FLBJ5HXSy+6lBbS1xFRDXbO f6z6nMExO0h+IDV6HEpqFlPdBjRCg+CU7VK2ntQhcj5A1SwuUnibpb+nJOCVeX/X NJtV8AA8RBBSpFDS6zvuqTHdmY1V7fnbMyQtJ3NrOCXLT41KQPVj1D51n74LDNe6 EKPHzKCZM= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9D2C8BAB48; Tue, 17 Jan 2017 19:21:21 -0500 (EST) Message-Id: <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> From: Bron Gondwana To: Ned Freed MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fd047210 References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> <01Q9SP1R5AP200004H@mauve.mrochek.com> In-Reply-To: <01Q9SP1R5AP200004H@mauve.mrochek.com> Date: Wed, 18 Jan 2017 11:21:21 +1100 Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 00:21:23 -0000 On Wed, 18 Jan 2017, at 10:43, Ned Freed wrote: > > > Then keep a record of the rejection for the user, as opposed to keeping a copy > > > of the message that was rejected. Indeed, if you're going to keep track > > > of all rejections you have to allow for this in order to deal with > > > rejections that occur before the message transferred. > > > OK, I see where the misunderstanding has come from. What I'm proposing is > > keeping a copy of the rejection. Basically the user wants a copy of every email > > sent on their behalf. > > When a Sieve ereject/reject occurs prior to delivery, and circumstances require > the use of a message as opposed to an SMTP status code, use of a DSN is > required. RFC 5429, section 2.1.2: > > In this case, the server MUST accept the message and generate DSNs for > all recipients that are refusing it. > > And DSNs are effectively required to contain at least a portion of > the rejected message. (There's an exception for DSNs generated by > gateways to foreign mail systems, but it clearly doesn't apply here.) > > Like it or not, these DSNs are "messages sent on [the users] behalf", and > they absolutely do contain part or all of the rejected message. > > > So as discovered above, we're talking past each other. I just want to keep a > > copy of the rejection that was sent out by sieve on the user's behalf. > > And such messages can and often do contain part or all of the original > message, creating exactly the issue I've been talking about. So we're back to this then. Do you also object to websites saying "404 not found" while still logging the fact that you tried to look at a resource? Sometimes you want to keep the junk that was sent to you while saying to the sender that nobody got that message. Making that hard within the standard will just cause people to work around it by doing things like capturing all mail that hits the MXes before sieve processes it. Not providing a facility because it can be used to lie doesn't change that. Bron. -- Bron Gondwana brong@fastmail.fm From nobody Tue Jan 17 16:32:14 2017 Return-Path: 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 453781293DC for ; Tue, 17 Jan 2017 16:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 FvJzdxd0nrLL for ; Tue, 17 Jan 2017 16:32:11 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 3A4AE129442 for ; Tue, 17 Jan 2017 16:32:11 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9SPQ81RKW000HTP@mauve.mrochek.com> for sieve@ietf.org; Tue, 17 Jan 2017 16:27:07 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Tue, 17 Jan 2017 16:27:05 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9SPQ6F0W000004H@mauve.mrochek.com> Date: Tue, 17 Jan 2017 16:24:12 -0800 (PST) In-reply-to: "Your message dated Wed, 18 Jan 2017 11:21:21 +1100" <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> <01Q9SP1R5AP200004H@mauve.mrochek.com> <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> To: Bron Gondwana Archived-At: Cc: sieve@ietf.org, Ned Freed Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 00:32:12 -0000 > > And such messages can and often do contain part or all of the original > > message, creating exactly the issue I've been talking about. > So we're back to this then. This has been the issue from the start. > Do you also object to websites saying "404 not found" > while still logging the fact that you tried to look at a resource? Nope. But the situations are not remotely comparable. No users involved, just for starters. > Sometimes you want to keep the junk that was sent to you while saying to the > sender that nobody got that message. Making that hard within the standard will > just cause people to work around it by doing things like capturing all mail that > hits the MXes before sieve processes it. Not providing a facility because it can be > used to lie doesn't change that. As I said before, if you really think it's perfectly OK to provide a mechanism to your users that allows them to instruct the system to lie in an offical system message about them not having gotten the content of a mail message, then we have nothing further to talk about. Ned From nobody Wed Jan 18 01:06:11 2017 Return-Path: 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 DA9F31293E8 for ; Wed, 18 Jan 2017 01:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni-koeln.de 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 Mr0Nz_WgT1DS for ; Wed, 18 Jan 2017 01:06:08 -0800 (PST) Received: from mail-out-v1.uni-koeln.de (mail-out-v1.uni-koeln.de [IPv6:2a00:a200:0:13::58]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4750128B44 for ; Wed, 18 Jan 2017 01:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-koeln.de; i=@uni-koeln.de; q=dns/txt; s=2016; t=1484730368; x=1516266368; h=date:from:to:cc:subject:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=x2TIewEUZqFMKAX8iMlDIQQep75DyFI6lySJSuul+i4=; b=qZGAPkyGEukW/ncf/4eVyYHySLQjPAEWp7vYQ3RHjLFVx0r6piVwzQY5 FaQkTA0NBKv4FRtAFOeFSy3i5AxB0AY/f+CFj4XEYT+qF+va+3MpB7VRl q1LtvjciKILgFi0ye/B8JCsQDXItSKDbhniZdRb03gyci5hFCOZnzgkU+ 5WHnaTI6d9P68mVj6tFb1JRqq3d5rfWL3jhis7pnO6+dgoYpGblQCko8g MvH6GhZXTBVZF/+fxtARytpTydVlEXk1hEwtNBsC1N1AIvGFEMUMhO/L9 5ZPaZQXfOurr1kC7xz1EorFSvE8fLvcTXfixVsZRUriXQpgEOzqEcq+kW A==; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A+ByBAAhL39Y/wCiACoSACVcGgEBAQECA?= =?us-ascii?q?QEBAQgBAQEBgxApAQEBAQEfUIEYg1GKepEelzeGIgKBZkIVAQIBAQEBAQEBYyi?= =?us-ascii?q?EagEEASMVQRALGgImAgJXGYh7CAGvNYIliioBAQEBBgEBAQEBASKBC4ohhCsBA?= =?us-ascii?q?RtMgjotgjEFmyIbPYISjxKKIAqGQ5JuNSKBJx6FBRyBYXKGTIIuAQEB?= X-IronPort-AV: E=Sophos;i="5.33,248,1477954800"; d="scan'208";a="7025732" Received: from smtp-out.rrz.uni-koeln.de ([IPv6:2a00:a200:0:12::25]) by mail-out-v1.uni-koeln.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2017 10:06:05 +0100 Received: from smtp.uni-koeln.de (milter2-neu.rrz.uni-koeln.de [IPv6:2a00:a200:0:15::27] (may be forged)) by smtp-out.rrz.uni-koeln.de (8.14.4/8.14.4) with ESMTP id v0I964Io019494; Wed, 18 Jan 2017 10:06:04 +0100 Received: from tyrion.rrz.uni-koeln.de (tyrion.rrz.uni-koeln.de [134.95.128.1]) by smtp.uni-koeln.de (8.14.4/8.14.4) with ESMTP id v0I963AA013944 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Jan 2017 10:06:04 +0100 Date: Wed, 18 Jan 2017 10:06:03 +0100 From: Sebastian Hagedorn To: NED+mta-filters@mauve.mrochek.com Message-ID: <012499BC3A68B6D107DF9613@tyrion.rrz.uni-koeln.de> In-Reply-To: <01Q9SPQ6F0W000004H@mauve.mrochek.com> References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> <01Q9SP1R5AP200004H@mauve.mrochek.com> <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> <01Q9SPQ6F0W000004H@mauve.mrochek.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1030 X-Scanned-By: MIMEDefang 2.78 Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 09:06:10 -0000 --On 17. Januar 2017 um 16:24:12 -0800 NED+mta-filters@mauve.mrochek.com=20 wrote: >> Sometimes you want to keep the junk that was sent to you while saying to >> the sender that nobody got that message. Making that hard within the >> standard will just cause people to work around it by doing things like >> capturing all mail that hits the MXes before sieve processes it. Not >> providing a facility because it can be used to lie doesn't change that. > > As I said before, if you really think it's perfectly OK to provide a > mechanism to your users that allows them to instruct the system to lie in > an offical system message about them not having gotten the content of a > mail message, then we have nothing further to talk about. For the record, I agree with Bron on this. It's up to the users if they=20 want to lie. --=20 .:.Sebastian Hagedorn - Weyertal 121 (Geb=C3=A4ude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universit=C3=A4t zu K=C3=B6ln / Cologne University - =E2=9C=86 = +49-221-470-89578.:. From nobody Wed Jan 18 04:07:43 2017 Return-Path: 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 6371A12948A for ; Wed, 18 Jan 2017 04:07:42 -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 6tvKxgkBFNAa for ; Wed, 18 Jan 2017 04:07:41 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.38]) (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 D58181294AB for ; Wed, 18 Jan 2017 04:07:40 -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 v0IC7c5A063552 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 18 Jan 2017 07:07:39 -0500 To: sieve@ietf.org References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> <01Q9SP1R5AP200004H@mauve.mrochek.com> <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> <01Q9SPQ6F0W000004H@mauve.mrochek.com> <012499BC3A68B6D107DF9613@tyrion.rrz.uni-koeln.de> From: Ken Murchison Organization: Carnegie Mellon University Message-ID: Date: Wed, 18 Jan 2017 07:07:38 -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: <012499BC3A68B6D107DF9613@tyrion.rrz.uni-koeln.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.1.18.115716 X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 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, NO_URI_HTTPS 0, REFERENCES 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 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_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0) X-SMTP-Spam-Score: 10% X-Scanned-By: MIMEDefang 2.78 on 128.2.157.38 Archived-At: Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 12:07:42 -0000 As it turns out, the point with soon be moot w.r.t. Cyrus. I realized last night that I never implemented ereject, and when I do, Cyrus will reject at the LMTP level and therefore no DSN or MDN. On 01/18/2017 04:06 AM, Sebastian Hagedorn wrote: > > --On 17. Januar 2017 um 16:24:12 -0800 > NED+mta-filters@mauve.mrochek.com wrote: > >>> Sometimes you want to keep the junk that was sent to you while >>> saying to >>> the sender that nobody got that message. Making that hard within the >>> standard will just cause people to work around it by doing things like >>> capturing all mail that hits the MXes before sieve processes it. Not >>> providing a facility because it can be used to lie doesn't change that. >> >> As I said before, if you really think it's perfectly OK to provide a >> mechanism to your users that allows them to instruct the system to >> lie in >> an offical system message about them not having gotten the content of a >> mail message, then we have nothing further to talk about. > > For the record, I agree with Bron on this. It's up to the users if > they want to lie. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Wed Jan 18 07:37:11 2017 Return-Path: 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 1C24E129461 for ; Wed, 18 Jan 2017 07:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 x3S_npOKAJ45 for ; Wed, 18 Jan 2017 07:37:09 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 31EBE126D73 for ; Wed, 18 Jan 2017 07:37:09 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9TLG5CIGG000UZL@mauve.mrochek.com> for sieve@ietf.org; Wed, 18 Jan 2017 07:35:16 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Wed, 18 Jan 2017 07:35:12 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9TLG2VN0W00004H@mauve.mrochek.com> Date: Wed, 18 Jan 2017 07:23:46 -0800 (PST) In-reply-to: "Your message dated Wed, 18 Jan 2017 07:07:38 -0500" References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> <01Q9SP1R5AP200004H@mauve.mrochek.com> <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> <01Q9SPQ6F0W000004H@mauve.mrochek.com> <012499BC3A68B6D107DF9613@tyrion.rrz.uni-koeln.de> To: Ken Murchison Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 15:37:10 -0000 > As it turns out, the point with soon be moot w.r.t. Cyrus. I realized > last night that I never implemented ereject, and when I do, Cyrus will > reject at the LMTP level and therefore no DSN or MDN. Yeah, I was going to mention that but forgot. This demonstrates a much more fundamental problem with this whole idea of, "I want copies of all the messages 'the system' sends on my behalf." If a message is rejected due to use policy encoded in sieve or wherever, it's always best to do that using a 5yz code over protocol, which obviously provides no fcc capabilities. This is also true if the reject occurs prior to delivery and the response is sent over SMTP. So unless you say that the use of :fcc requires local generation of the DSN - in the process making your system generate more blowback spam that it would otherwise - you end up in a situation where the user only receives copies of the subset of messages that happened to require local DSN generation for some other reason. And that's a pretty significant violation of the least astonishment principle. I suppose you could do a hack where you generate your own version of DSN you assume the SMTP client is going to create and stuff that in the user's folder. But really, isn't this whole thing getting a little silly? Ned From nobody Wed Jan 18 07:42:59 2017 Return-Path: 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 4680C1293E0 for ; Wed, 18 Jan 2017 07:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.101 X-Spam-Level: X-Spam-Status: No, score=-5.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 lJHgf4IvHYlz for ; Wed, 18 Jan 2017 07:42:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 63931127076 for ; Wed, 18 Jan 2017 07:42:57 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9TLJXVOM8000UZL@mauve.mrochek.com> for sieve@ietf.org; Wed, 18 Jan 2017 07:38:19 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q9Q42VM1B400004H@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Wed, 18 Jan 2017 07:38:14 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01Q9TLJTUF9E00004H@mauve.mrochek.com> Date: Wed, 18 Jan 2017 07:36:26 -0800 (PST) In-reply-to: "Your message dated Wed, 18 Jan 2017 10:06:03 +0100" <012499BC3A68B6D107DF9613@tyrion.rrz.uni-koeln.de> References: <1484691459.1802986.850940944.17135021@webmail.messagingengine.com> <01Q9SN4A5CB400004H@mauve.mrochek.com> <1484695748.520887.851011408.2EB11064@webmail.messagingengine.com> <01Q9SP1R5AP200004H@mauve.mrochek.com> <1484698881.2689745.851047760.743150E6@webmail.messagingengine.com> <01Q9SPQ6F0W000004H@mauve.mrochek.com> <012499BC3A68B6D107DF9613@tyrion.rrz.uni-koeln.de> To: Sebastian Hagedorn Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] On "reject" and :fcc X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 15:42:58 -0000 > For the record, I agree with Bron on this. It's up to the users if they > want to lie. I have no problem with users lying to other users. I have a big problem with them being able to trick the system into lying on their behalf. Ned From nobody Tue Jan 24 07:34:34 2017 Return-Path: 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 AE101129A54 for ; Tue, 24 Jan 2017 07:34:32 -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 Cp7B1cmcC-OI for ; Tue, 24 Jan 2017 07:34:31 -0800 (PST) Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.105.204]) (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 62AC512945A for ; Tue, 24 Jan 2017 07:34:31 -0800 (PST) Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v0OFYSNA001337 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Jan 2017 10:34:29 -0500 To: sieve@ietf.org From: Ken Murchison Organization: Carnegie Mellon University Message-ID: Date: Tue, 24 Jan 2017 10:34:27 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.10.23617 X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODYTEXTP_SIZE_400_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 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, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0) X-SMTP-Spam-Score: 33% X-Scanned-By: MIMEDefang 2.78 on 128.2.105.204 Archived-At: Subject: [sieve] Sieve :index and string/hasflag tests X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 15:34:33 -0000 All, I just noticed that the :index extension has leaked into our grammar for the string and hasflag tests. I can't think of any use case for this combination but wanted to check with the community before I rip it out. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University From nobody Thu Jan 26 12:36:21 2017 Return-Path: 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 0065F129B13 for ; Thu, 26 Jan 2017 12:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 LhOpr-NA8ye1 for ; Thu, 26 Jan 2017 12:36:19 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 257F1129AD6 for ; Thu, 26 Jan 2017 12:36:19 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QA524W1VPC003NEX@mauve.mrochek.com> for sieve@ietf.org; Thu, 26 Jan 2017 12:31:17 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QA4UGNSGZK0003XB@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Thu, 26 Jan 2017 12:31:14 -0800 (PST) From: NED+mta-filters@mauve.mrochek.com Message-id: <01QA524UZB640003XB@mauve.mrochek.com> Date: Thu, 26 Jan 2017 12:29:50 -0800 (PST) In-reply-to: "Your message dated Tue, 24 Jan 2017 10:34:27 -0500" References: To: Ken Murchison Archived-At: Cc: sieve@ietf.org Subject: Re: [sieve] Sieve :index and string/hasflag tests X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 20:36:20 -0000 > All, > I just noticed that the :index extension has leaked into our grammar for > the string and hasflag tests. I can't think of any use case for this > combination but wanted to check with the community before I rip it out. I can't think of a meaning either and our implementation doesn't allow :index to be combined with string or hasflag (although since we implement ihave it's an evaluation time check). Ned