From owner-ietf-mta-filters@mail.imc.org Mon Aug 6 09:49:32 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_40, DATE_IN_PAST_03_06 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l76EnRT08642 for ; Mon, 6 Aug 2007 09:49:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76EcYkt015538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 07:38:34 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l76EcYQL015537; Mon, 6 Aug 2007 07:38:34 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76EcX2i015528 for ; Mon, 6 Aug 2007 07:38:34 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 6 Aug 2007 15:37:51 +0100 Message-ID: <46B6E07A.8050008@isode.com> Date: Mon, 06 Aug 2007 09:48:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: ietf-mta-filters@imc.org Subject: WGLC on draft-ietf-sieve-mime-loop MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Hi, This message officially starts the Sieve Working Group Last Call for the following document: SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and Enclosure The Working Group Last Call for this document starts on August 6th and will end on August 20th. Please send any comments to the Sieve mailing list or directly to me. Please CC Tony Hansen and Cyrus Daboo in the latter case. Reviews that found no issues are also welcomed, so if you review the document and find it acceptable, please let the mailing list/authors+me know as well. Thank you, Alexey, Sieve WG co-chairs From owner-ietf-mta-filters@mail.imc.org Mon Aug 6 11:07:38 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l76G7VT23554 for ; Mon, 6 Aug 2007 11:07:33 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76FthnK023041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 08:55:43 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l76FtgnI023040; Mon, 6 Aug 2007 08:55:43 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from smtp.aegee.uni-karlsruhe.de (smtp.aegee.uni-karlsruhe.de [129.13.62.220]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l76Fte91023032 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 6 Aug 2007 08:55:42 -0700 (MST) (envelope-from Dilyan.Palauzov@aegee.org) Received: from smtp.aegee.org (aegeeserv.aegee.uni-karlsruhe.de [129.13.131.80]) by smtp2.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1II4vh-0007lB-9x; Mon, 06 Aug 2007 17:55:37 +0200 X-Mail-Sent-By-AEGEE.org-Account: Dilyan Palauzov@aegee.org Received: from [172.20.21.213] (nan-y403.nan.uni-karlsruhe.de [172.20.21.213]) (authenticated bits=0) by smtp.aegee.org (8.14.1/8.13.6) with ESMTP id l76Ftekh011637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Aug 2007 15:55:40 GMT Message-ID: <46B7447A.9080105@aegee.org> Date: Mon, 06 Aug 2007 17:55:38 +0200 From: Dilyan Palauzov User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Alexey Melnikov CC: ietf-mta-filters@imc.org Subject: Re: WGLC on draft-ietf-sieve-mime-loop References: <46B6E07A.8050008@isode.com> In-Reply-To: <46B6E07A.8050008@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.1/3874/Mon Aug 6 00:38:49 2007 on AEGEEserv.aegee.uni-karlsruhe.de X-Virus-Status: Clean Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Hello, > 7 Action extract_text > QUESTION: What do we do if the Content-Transfer-Encoding is anything other than 7bit? If it is 8bit, we take the :first number characters (not bytes), taking into account the "charset=" parameter of the Content-Type header, when presented. If it is base64 or quoted-printable, we convert it to 8bit and proceed as if it was 8bit. The same for binary, even if the result will be probably useless. (The useless results can happen using base64, too, but the possibility is smaller) > :type, :subtype, :contenttype What is the obvious advantage of having them, compared to header :contains ? I mean, isn't 'header :contains "Content-Type" "text/"' as powerful, as 'header :type "Context-Type" "text"'? If this was discussed already on this list, could you tell me the starting date? Със здраве, Дилян Alexey Melnikov wrote: > > Hi, > > This message officially starts the Sieve Working Group Last Call for > the following document: > SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and > Enclosure > > > The Working Group Last Call for this document starts on August 6th and > will end on August 20th. > > Please send any comments to the Sieve mailing list or directly to me. > Please CC Tony Hansen and Cyrus Daboo > in the latter case. Reviews that found no issues > are also welcomed, so if you review the document and find it > acceptable, please let the mailing list/authors+me know as well. > > Thank you, > Alexey, Sieve WG co-chairs > > > From owner-ietf-mta-filters@mail.imc.org Fri Aug 10 11:19:56 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=4.0 tests=BAYES_50 autolearn=no version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7AGJpW26468 for ; Fri, 10 Aug 2007 11:19:53 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AG4xKF058818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:04:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AG4xMM058817; Fri, 10 Aug 2007 09:04:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AG4waF058807 for ; Fri, 10 Aug 2007 09:04:58 -0700 (MST) (envelope-from Nigel.Swinson@mailsite.com) Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id for ; Fri, 10 Aug 2007 09:04:31 -0700 Message-ID: <007f01c7db68$230c5140$d201a8c0@nigelhome> From: "Nigel Swinson" To: Subject: Naming conventions for Sieve RFCs Date: Fri, 10 Aug 2007 17:03:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Did we decide on a naming convention for Sieve extensions? We seem to have either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it would be helpful to be consistent. Looking for a precedent from the existing RFCs we have: RFC3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002. (Format: TXT=12849 bytes) (Status: PROPOSED STANDARD) RFC3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison. September 2003. (Format: TXT=11151 bytes) (Status: PROPOSED STANDARD) RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C. Daboo. February 2004. (Format: TXT=17436 bytes) (Status: PROPOSED STANDARD) RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener. October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD) http://www.ietf.org/html.charters/sieve-charter.html lists the other I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has the majority vote just now. That means we should change these if possible: http://tools.ietf.org/html/draft-ietf-sieve-variables Sieve Extension: Variables http://tools.ietf.org/html/draft-ietf-sieve-notify-08 Sieve Extension: Notifications http://tools.ietf.org/html/draft-ietf-sieve-3431bis-04 Sieve Extension: Relational Tests Nigel From owner-ietf-mta-filters@mail.imc.org Fri Aug 10 11:44:07 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=4.0 tests=AWL,BAYES_40 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7AGhwW00859 for ; Fri, 10 Aug 2007 11:44:00 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGVucD062193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:31:56 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AGVubV062192; Fri, 10 Aug 2007 09:31:56 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGVrKQ062185 for ; Fri, 10 Aug 2007 09:31:55 -0700 (MST) (envelope-from Nigel.Swinson@mailsite.com) Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id for ; Fri, 10 Aug 2007 09:31:46 -0700 Message-ID: <008c01c7db6b$f1933ad0$d201a8c0@nigelhome> From: "Nigel Swinson" To: References: <46B6E07A.8050008@isode.com> Subject: Re: WGLC on draft-ietf-sieve-mime-loop Date: Fri, 10 Aug 2007 17:31:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean WRT to: http://tools.ietf.org/html/draft-ietf-sieve-mime-loop-03 and some related discussion of http://tools.ietf.org/html/draft-ietf-sieve-body-06 Abstract I don't think it's necessary to start the abstract by saying what can't be done with an existing standard. By stating what this extension offers you implicitly propose that no other standard offers this. - The Sieve email filtering language has no way to examine individual - MIME parts or any way to manipulate those individual parts. However, - being able to filter based on MIME content is important. This - document defines extensions for these needs. + This document defines extensions to the Sieve email filtering language + to permit analysis and manipulation of the MIME body parts of an email + message. 1. Introduction I don't think it's necessary to justify the current extension based on what other standards don't allow you to do. Also while it might be helpful to refer to other related standards, it seems to just create headaches when you want to revise the standard later, so I'd suggest: - Sieve scripts are used to make decisions about the disposition of an - email message. The base Sieve specification, - [I-D.ietf-sieve-3028bis], defines operators for looking at the - message headers, such as addresses and the subject. Other extensions - provide access to the body of the message ([I-D.ietf-sieve-body]), or - allow you to manipulate the header of the message - ([I-D.ietf-sieve-editheader]). But none of these extensions take - into account that MIME messages ([RFC2045]) are often complex MIME messages ([RFC2045]) are often complex objects, consisting of many parts and sub-parts. This extension defines mechanisms for performing tests on MIME body parts, looping through the MIME body parts, extracting information from a MIME body part, changing the contents of a MIME body part, and enclosing the - entire message with a wrapper. + entire message within a wrapper. 3. Sieve Loops The base Sieve language has no looping mechanism. Given that messages may contain multiple parts, in order to support filters that apply to any and all parts, we introduce a new control command: "for_every_part", which is an iterator that walks though every MIME part of a message, including nested parts, and applies the commands in the specified block to each of them. The iterator will start with the first MIME part (as its current context) and will execute a - command block (Sieve commands enclosed by { ...}). Upon completion + command block (Sieve commands enclosed by {...}). Upon completion of this command block, the iterator advances to the next MIME part (as its current context) and executes the same command block again. "for_every_part" commands can be nested inside other "for_every_part" commands. When this occurs, the nested "for_every_part" iterates - over the MIME parts contained within the MIME part current being + over the MIME parts contained within the MIME part currently being targeted by the nearest enclosing "for_every_part" command. If that MIME part is a terminal MIME part (i.e. does not contain other MIME parts) then the nested "for_every_loop" is simply ignored. 4.1. Test "header" The "header" test is extended with the addition of a new ":mime" - tagged argument, which takes a number of other arguments. + tagged argument and its associated options. Usage: header [:mime] [:anychild] [MIMEOPTS] [COMPARATOR] [MATCH-TYPE] Usage: The definition of [MIMEOPTS] is: Syntax: ":type" / ":subtype" / ":contenttype" / ":param" When the ":mime" tagged argument is present in the "header" test, it - will parse the MIME header lines in a message so that tests can be + will parse the MIME header lines in the message so that tests can be performed on specific elements. I don't think the section below reads well, as I think the list with introductory partial sentence construct should mean you can prefix each list item with the indroductory partial sentence and it still read well. Below you'd end up with: - If the ":anychild" tagged argument is NOT specified if used within the context of a "for_every_part" iterator, etc.... - If the ":anychild" tagged argument is NOT specified if used outside the context of a "for_every_part" iterator, etc... Also I think the behaviour should be explained when :anychild is used with for_every_part. - If the ":anychild" tagged argument is NOT specified: - - o If used within the context of a "for_every_part" iterator, the - "header" test will examine the headers associated with the current - MIME part context from the loop. - - o If used outside the context of a "for_every_part" iterator, the - "header" test will examine only the outer, top-level, headers of - the message. + When used outside the context of a "for_every_part" iterator, and + without an ":anychild" tagged argument, the "header" test will examine + only the outer top-level RFC2822 headers of the message. + + When used inside the context of a "for_every_part" iterator, and + without an ":anychild" tagged argument, the "header" test will examine + the headers associated with the current MIME part context from the loop. + - If the ":anychild" tagged argument IS specified, the "header" test + When used outside the context of a "for_every_part" iterator, and + with an ":anychild" tagged argument, the "header" test will examine all MIME body parts and return true if any of them satisfies the test. + + When used inside the context of a "for_every_part" iterator, and + with an ":anychild" tagged argument, the "header" test will examine + the current MIME part context and all it's nested MIME body parts, + returning true if any of them satisfies the test. Example: require ["mime", "fileinto"]; - if header :mime :anychild :contenttype :comparator + if header :mime :anychild :contenttype "Content-Type" "text/html" { fileinto "INBOX.html"; } In this example, any message that contains any MIME part with a content-type of "text/html" is saved to the mailbox "INBOX.html". Reading over this again I don't think it's clear when you should use for_every_part, and when you should use :anychild. I think we should offer an example that illustrates why we have both mechanisms. Consider the question, "Which one of these should I use: if header :mime :anychild :contenttype :comparator "Content-Type" "text/html" { ... } Or: for_every_part { if header :mime :contenttype :comparator "Content-Type" "text/html" { ... } } Perhaps change the for_every_part example. It had the same ":comparator" bug that the previous example had anyway. Example: require ["mime", "for_every_part", "fileinto"]; for_every_part { + if allof ( - if header :mime :param "filename" :comparator - "Content-Disposition" "important" + header :mime :param "filename" :contains + "Content-Disposition" "important", + header :mime :subtype "Content-Type" "pdf", + size :over "100K") { fileinto "INBOX.important"; break; } } - In this example, any message that contains any MIME part with a - content-disposition with a filename parameter containing the text - "important" is saved to the mailbox "INBOX.important". + In this example, any message that contains a MIME part that + has a content-disposition with a filename parameter containing the text + "important", has a content-subtype of "pdf" and is bigger than 100 Kb + is saved to the mailbox "INBOX.important". 4.2. Test "address" I've tried and failed to find any specification on the "content-from" header. Perhaps partially because googling for the term "content-from" is fairly unfruitful, and there's no mention in 2045. So I'd suggest this section be dropped, or changed to reference where "content-from" is defined. I'm also not clear at all why you can't just use a vanilla address test. ie why doesn't this work: if address :is :all "content-from" "tim@example.com" I can understand utility in: if address :mime :anychild :is :all "content-from" tim@example.com In which case I'd rather it was just: if address :anychild :is :all "content-from" tim@example.com And the ":mime" be the way of accessing the type, subtype, parameters of those structured headers. 4.3. Test "exists" Again I don't see why you couldn't just write: if exists :anychild "content-md5" 5. Action Replace If the :mime parameter is not specified, the replacement string is a - text/plain part. + text/plain part in UTF-8. If the :mime parameter is specified, then the replacement string is, in fact, a MIME entity as defined in [RFC2045] section 2.4, including + both MIME headers and content. - both MIME headers and content. If the optional :mime parameter is - not supplied, the reason string is considered to be a UTF-8 string. 6. Action Enclose A new Sieve action command is defined to allow an entire message to be enclosed as an attachment to a new message. After enclosure, subsequent actions affecting the message header or content use the - newly create message instead of the original message; this means that + newly created message instead of the original message; this means that any use of a "replace" action or other similar actions should be executed before the "enclose" action. The text implies that enclose happens immediately, and therefore subsequent actions affecting the message header/content apply to the enclosing message, but then it goes on to say if there are multiple enclose actions, then it's only the last one that will win. This means if I have an enclose action, I'll have to remember that the outer body part is the new "enclosing" body part, and should I get another enclose action then I should "replace" that enclosing body part rather than enclose the message yet again such that it has two layers of enclosing. This sounds like a real hassle to implement for questionable utility, I'd rather two enclose actions just add two layers of enclosing mime structure and body text body parts be present. Just like they would if the message goes through two separate Sieve scripts, both of which add an enclose. Either that or define that the enclose action should happen at the end of the script and therefore doesn't affect the mime structure during the existing processing (that might even be inside a for_every_part construct). I'd actually suggest we leave it to the implementation like we do for fileinto. The implementation can choose to have the enclose happen immediately, or at the end. 7. Action extract_text Shouldn't we leave this to the body test? I know in section 5 of http://tools.ietf.org/html/draft-ietf-sieve-body-06 it says that we shouldn't set the match variables, but perhaps it should define an optional argument of :extracttext in the body spec to do this if we really wanted them. 8. Sieve Capability Strings - A Sieve implementation that defines the ":mime" tagged arguments to + A Sieve implementation that defines the ":mime" tagged argument to + the "header" test and the ":anychild" tagged argument to the "header", "address" and "exists" commands will advertise the capability string "mime". A Sieve implementation that defines the "extract_text" action will advertise the capability string "extract_text". Note that to be useful, the "extract_text" action also requires the "variables" - [I-D.ietf-sieve-variables] and "mime" capabilities. + [I-D.ietf-sieve-variables] and "for_every_part" capabilities. 9.1. Example 1 A Sieve script to replace all the Windows executable attachments in a message would be: This example isn't indented either and should be: require [ "for_every_part", "mime", "replace" ]; for_every_part { - if ( anyof ( + if anyof ( header :mime :contenttype :is "Content-Type" "application/exe", header :mime :param "filename" ["Content-Type", "Content-Disposition"] :matches "*.com" ) { replace "Executable attachment removed by user filter"; } } 9.2. Example 2 A Sieve script to warn the user about executable attachment types would be: require [ "for_every_part", "mime", "enclose" ]; for_every_part { if header :mime :param "filename" ["Content-Type", "Content-Disposition"] :matches ["*.com", "*.exe", "*.vbs", "*.scr", "*.pif", "*.hta", "*.bat", "*.zip" ] { # these attachment types are executable - enclose :subject "Warning" " + enclose :subject "Warning" text: WARNING! The enclosed message contains executable attachments. These attachments types may contain a computer virus program - that can infect your computer and potentently damage your data + that can infect your computer and potentently damage your data. Before clicking on these message attachments, you should verify with the sender that this message was sent by them and not a computer virus. - "; . break; } } 9.3. Example 3 A Sieve script to extract subject and text out of messages from the - boss boss: 11. Security Considerations The "enclose" action creates an entirely new message, as compared to just redirecting or forwarding the existing message. Therefore, any site policies applicable to message submission should be enforced. - site policies applicable to message submission should be enforced - here. The looping specification specified here provides easier access to information about the message contents, which may also be achieved through other sieve tests. This is not believed to raise any additional security issues beyond those for the Sieve "envelope" and + "body" ([I-D.ietf-sieve-body]) tests. - "body" tests. Cheers Nigel From owner-ietf-mta-filters@mail.imc.org Fri Aug 10 11:51:43 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7AGpaW03899 for ; Fri, 10 Aug 2007 11:51:39 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGeJsR062810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 09:40:19 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AGeJ1N062809; Fri, 10 Aug 2007 09:40:19 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AGeIhL062803 for ; Fri, 10 Aug 2007 09:40:18 -0700 (MST) (envelope-from Nigel.Swinson@mailsite.com) Received: from nigelhome (unverified [10.42.40.204]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id ; Fri, 10 Aug 2007 09:40:13 -0700 Message-ID: <009601c7db6d$1ff9c7d0$d201a8c0@nigelhome> From: "Nigel Swinson" To: "Dilyan Palauzov" Cc: References: <46B6E07A.8050008@isode.com> <46B7447A.9080105@aegee.org> Subject: Re: WGLC on draft-ietf-sieve-mime-loop Date: Fri, 10 Aug 2007 17:40:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > > 7 Action extract_text > > > QUESTION: What do we do if the Content-Transfer-Encoding is anything other than 7bit? > > If it is 8bit, we take the :first number characters (not bytes), taking into account the > "charset=" parameter of the Content-Type header, when presented. If it is base64 or > quoted-printable, we convert it to 8bit and proceed as if it was 8bit. The same for binary, > even if the result will be probably useless. (The useless results can happen using base64, > too, but the possibility is smaller) I guess the reason this is a problem is if you hit some 10MB base64 encoded attachment and are trying to extract the first 100 bytes. You either have to decode the whole 10MB, or write some picky code to extract as little text as possible while decoding legal units of QP/base64 encoding. With the body test we offer :raw :content :text to decide what kind of transform is required, which is why I believe extract_text should be moved to the body spec, and implemented through an optional argument to force the setting of the match variables. > > :type, :subtype, :contenttype > > What is the obvious advantage of having them, compared to header :contains ? I mean, isn't > 'header :contains "Content-Type" "text/"' as powerful, as 'header :type "Context-Type" > "text"'? If this was discussed already on this list, could you tell me the starting date? It's a matter of precision of parsing. Consider: header :contains "Content-Type" "text" and header :type "Content-Type" "text" Against this content-type header: Content-Type: application/pdf; name="presentationtext.pdf" Nigel From owner-ietf-mta-filters@mail.imc.org Fri Aug 10 12:30:11 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7AHU6W17402 for ; Fri, 10 Aug 2007 12:30:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AHBQdv065998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Aug 2007 10:11:26 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7AHBQHd065997; Fri, 10 Aug 2007 10:11:26 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7AHBPSf065990 for ; Fri, 10 Aug 2007 10:11:26 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.palo-alto.ca.us (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with SMTP id B6D3D1EE1; Fri, 10 Aug 2007 10:14:29 -0700 (PDT) Date: Fri, 10 Aug 2007 17:14:29 -0000 To: "Nigel Swinson" Subject: Re: WGLC on draft-ietf-sieve-mime-loop From: "Aaron Stone" X-Mailer: TWIG 2.8.3 Message-ID: In-Reply-To: <008c01c7db6b$f1933ad0$d201a8c0@nigelhome> References: <46B6E07A.8050008@isode.com> Cc: Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean I like these edits a lot! +1 (with a very large value of 1). One editing note, recall that RFC's should always use the Oxford comma in lists of three items or more. I've noted two missing commas below. (Sorry, this is uber-nit-picking; the RFC Editor should pick these up anyways.) Aaron On Fri, Aug 10, 2007, Nigel Swinson said: > > WRT to: http://tools.ietf.org/html/draft-ietf-sieve-mime-loop-03 and some > related discussion of http://tools.ietf.org/html/draft-ietf-sieve-body-06 > > Abstract > > I don't think it's necessary to start the abstract by saying what can't be > done with an existing standard. By stating what this extension offers you > implicitly propose that no other standard offers this. > > - The Sieve email filtering language has no way to examine individual > - MIME parts or any way to manipulate those individual parts. However, > - being able to filter based on MIME content is important. This > - document defines extensions for these needs. > + This document defines extensions to the Sieve email filtering language > + to permit analysis and manipulation of the MIME body parts of an email > + message. > > 1. Introduction > > I don't think it's necessary to justify the current extension based on what > other standards don't allow you to do. Also while it might be helpful to > refer to other related standards, it seems to just create headaches when you > want to revise the standard later, so I'd suggest: > > - Sieve scripts are used to make decisions about the disposition of an > - email message. The base Sieve specification, > - [I-D.ietf-sieve-3028bis], defines operators for looking at the > - message headers, such as addresses and the subject. Other extensions > - provide access to the body of the message ([I-D.ietf-sieve-body]), or > - allow you to manipulate the header of the message > - ([I-D.ietf-sieve-editheader]). But none of these extensions take > - into account that MIME messages ([RFC2045]) are often complex > MIME messages ([RFC2045]) are often complex > objects, consisting of many parts and sub-parts. This extension > defines mechanisms for performing tests on MIME body parts, looping > through the MIME body parts, extracting information from a MIME body > part, changing the contents of a MIME body part, and enclosing the > - entire message with a wrapper. > + entire message within a wrapper. > > 3. Sieve Loops > > The base Sieve language has no looping mechanism. Given that > messages may contain multiple parts, in order to support filters that > apply to any and all parts, we introduce a new control command: > "for_every_part", which is an iterator that walks though every MIME > part of a message, including nested parts, and applies the commands > in the specified block to each of them. The iterator will start with > the first MIME part (as its current context) and will execute a > - command block (Sieve commands enclosed by { ...}). Upon completion > + command block (Sieve commands enclosed by {...}). Upon completion > of this command block, the iterator advances to the next MIME part > (as its current context) and executes the same command block again. > > > "for_every_part" commands can be nested inside other "for_every_part" > commands. When this occurs, the nested "for_every_part" iterates > - over the MIME parts contained within the MIME part current being > + over the MIME parts contained within the MIME part currently being > targeted by the nearest enclosing "for_every_part" command. If that > MIME part is a terminal MIME part (i.e. does not contain other MIME > parts) then the nested "for_every_loop" is simply ignored. > > 4.1. Test "header" > > The "header" test is extended with the addition of a new ":mime" > - tagged argument, which takes a number of other arguments. > + tagged argument and its associated options. > > Usage: header [:mime] [:anychild] [MIMEOPTS] > [COMPARATOR] [MATCH-TYPE] > > > Usage: The definition of [MIMEOPTS] is: > > Syntax: ":type" / ":subtype" / ":contenttype" / > ":param" > > When the ":mime" tagged argument is present in the "header" test, it > - will parse the MIME header lines in a message so that tests can be > + will parse the MIME header lines in the message so that tests can be > performed on specific elements. > > I don't think the section below reads well, as I think the list with > introductory partial sentence construct should mean you can prefix each list > item with the indroductory partial sentence and it still read well. Below > you'd end up with: > > - If the ":anychild" tagged argument is NOT specified if used within the > context of a "for_every_part" iterator, etc.... > - If the ":anychild" tagged argument is NOT specified if used outside the > context of a "for_every_part" iterator, etc... > > Also I think the behaviour should be explained when :anychild is used with > for_every_part. > > - If the ":anychild" tagged argument is NOT specified: > - > - o If used within the context of a "for_every_part" iterator, the > - "header" test will examine the headers associated with the current > - MIME part context from the loop. > - > - o If used outside the context of a "for_every_part" iterator, the > - "header" test will examine only the outer, top-level, headers of > - the message. > + When used outside the context of a "for_every_part" iterator, and > + without an ":anychild" tagged argument, the "header" test will examine > + only the outer top-level RFC2822 headers of the message. > + > + When used inside the context of a "for_every_part" iterator, and > + without an ":anychild" tagged argument, the "header" test will examine > + the headers associated with the current MIME part context from the loop. > + > - If the ":anychild" tagged argument IS specified, the "header" test > + When used outside the context of a "for_every_part" iterator, and > + with an ":anychild" tagged argument, the "header" test > will examine all MIME body parts and return true if any of them > satisfies the test. > + > + When used inside the context of a "for_every_part" iterator, and > + with an ":anychild" tagged argument, the "header" test will examine > + the current MIME part context and all it's nested MIME body parts, > + returning true if any of them satisfies the test. > > > Example: > > require ["mime", "fileinto"]; > > - if header :mime :anychild :contenttype :comparator > + if header :mime :anychild :contenttype > "Content-Type" "text/html" > { > fileinto "INBOX.html"; > } > > In this example, any message that contains any MIME part with a > content-type of "text/html" is saved to the mailbox "INBOX.html". > > Reading over this again I don't think it's clear when you should use > for_every_part, and when you should use :anychild. I think we should offer > an example that illustrates why we have both mechanisms. Consider the > question, "Which one of these should I use: > > if header :mime :anychild :contenttype :comparator > "Content-Type" "text/html" > { ... } > > Or: > > for_every_part { > if header :mime :contenttype :comparator > "Content-Type" "text/html" > { ... } > } > > Perhaps change the for_every_part example. It had the same ":comparator" > bug that the previous example had anyway. > > Example: > > require ["mime", "for_every_part", "fileinto"]; > > for_every_part > { > > + if allof ( > - if header :mime :param "filename" :comparator > - "Content-Disposition" "important" > + header :mime :param "filename" :contains > + "Content-Disposition" "important", > + header :mime :subtype "Content-Type" "pdf", > + size :over "100K") > { > fileinto "INBOX.important"; > break; > } > } > > - In this example, any message that contains any MIME part with a > - content-disposition with a filename parameter containing the text > - "important" is saved to the mailbox "INBOX.important". > > + In this example, any message that contains a MIME part that > + has a content-disposition with a filename parameter containing the text > + "important", has a content-subtype of "pdf" and is bigger than 100 Kb > + is saved to the mailbox "INBOX.important". needs a comma after "pdf". > > 4.2. Test "address" > > I've tried and failed to find any specification on the "content-from" > header. Perhaps partially because googling for the term "content-from" is > fairly unfruitful, and there's no mention in 2045. So I'd suggest this > section be dropped, or changed to reference where "content-from" is defined. > I'm also not clear at all why you can't just use a vanilla address test. ie > why doesn't this work: > > if address :is :all "content-from" "tim@example.com" > > I can understand utility in: > > if address :mime :anychild :is :all "content-from" tim@example.com > > In which case I'd rather it was just: > > if address :anychild :is :all "content-from" tim@example.com > > And the ":mime" be the way of accessing the type, subtype, parameters of > those structured headers. > > 4.3. Test "exists" > > Again I don't see why you couldn't just write: > > if exists :anychild "content-md5" > > 5. Action Replace > > If the :mime parameter is not specified, the replacement string is a > - text/plain part. > + text/plain part in UTF-8. > > If the :mime parameter is specified, then the replacement string is, > in fact, a MIME entity as defined in [RFC2045] section 2.4, including > + both MIME headers and content. > - both MIME headers and content. If the optional :mime parameter is > - not supplied, the reason string is considered to be a UTF-8 string. > > 6. Action Enclose > > A new Sieve action command is defined to allow an entire message to > be enclosed as an attachment to a new message. After enclosure, > subsequent actions affecting the message header or content use the > - newly create message instead of the original message; this means that > + newly created message instead of the original message; this means that > any use of a "replace" action or other similar actions should be > executed before the "enclose" action. > > The text implies that enclose happens immediately, and therefore subsequent > actions affecting the message header/content apply to the enclosing message, > but then it goes on to say if there are multiple enclose actions, then it's > only the last one that will win. This means if I have an enclose action, > I'll have to remember that the outer body part is the new "enclosing" body > part, and should I get another enclose action then I should "replace" that > enclosing body part rather than enclose the message yet again such that it > has two layers of enclosing. > > This sounds like a real hassle to implement for questionable utility, I'd > rather two enclose actions just add two layers of enclosing mime structure > and body text body parts be present. Just like they would if the message > goes through two separate Sieve scripts, both of which add an enclose. > Either that or define that the enclose action should happen at the end of > the script and therefore doesn't affect the mime structure during the > existing processing (that might even be inside a for_every_part construct). > I'd actually suggest we leave it to the implementation like we do for > fileinto. The implementation can choose to have the enclose happen > immediately, or at the end. > > 7. Action extract_text > > Shouldn't we leave this to the body test? I know in section 5 of > http://tools.ietf.org/html/draft-ietf-sieve-body-06 it says that we > shouldn't set the match variables, but perhaps it should define an optional > argument of :extracttext in the body spec to do this if we really wanted > them. > > 8. Sieve Capability Strings > > - A Sieve implementation that defines the ":mime" tagged arguments to > + A Sieve implementation that defines the ":mime" tagged argument to > + the "header" test and the ":anychild" tagged argument to > the "header", "address" and "exists" commands will advertise the > capability string "mime". Needs a comma after "address". > A Sieve implementation that defines the "extract_text" action will > advertise the capability string "extract_text". Note that to be > useful, the "extract_text" action also requires the "variables" > - [I-D.ietf-sieve-variables] and "mime" capabilities. > + [I-D.ietf-sieve-variables] and "for_every_part" capabilities. > > 9.1. Example 1 > > A Sieve script to replace all the Windows executable attachments in a > message would be: > > This example isn't indented either and should be: > > require [ "for_every_part", "mime", "replace" ]; > for_every_part > { > - if ( anyof ( > + if anyof ( > header :mime :contenttype :is "Content-Type" "application/exe", > header :mime :param "filename" > ["Content-Type", "Content-Disposition"] :matches "*.com" ) > { > replace "Executable attachment removed by user filter"; > } > } > > 9.2. Example 2 > > A Sieve script to warn the user about executable attachment types > would be: > > require [ "for_every_part", "mime", "enclose" ]; > > for_every_part > { > if header :mime :param "filename" > ["Content-Type", "Content-Disposition"] :matches > ["*.com", "*.exe", "*.vbs", "*.scr", > "*.pif", "*.hta", "*.bat", "*.zip" ] > { > # these attachment types are executable > - enclose :subject "Warning" " > + enclose :subject "Warning" text: > WARNING! The enclosed message contains executable attachments. > These attachments types may contain a computer virus program > - that can infect your computer and potentently damage your data > + that can infect your computer and potentently damage your data. > > Before clicking on these message attachments, you should verify > with the sender that this message was sent by them and not a > computer virus. > - "; > . > break; > } > } > > 9.3. Example 3 > > A Sieve script to extract subject and text out of messages from the > - boss > boss: > > 11. Security Considerations > > The "enclose" action creates an entirely new message, as compared to > just redirecting or forwarding the existing message. Therefore, any > site policies applicable to message submission should be enforced. > - site policies applicable to message submission should be enforced > - here. > > The looping specification specified here provides easier access to > information about the message contents, which may also be achieved > through other sieve tests. This is not believed to raise any > additional security issues beyond those for the Sieve "envelope" and > + "body" ([I-D.ietf-sieve-body]) tests. > - "body" tests. > > Cheers > > Nigel > > -- From owner-ietf-mta-filters@mail.imc.org Sat Aug 11 08:28:57 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7BDSbW27653 for ; Sat, 11 Aug 2007 08:28:38 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BDHKYf064983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 06:17:20 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7BDHKA9064982; Sat, 11 Aug 2007 06:17:20 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BDHJ0b064968 for ; Sat, 11 Aug 2007 06:17:19 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 11 Aug 2007 14:17:16 +0100 Message-ID: <46BD8750.5040200@isode.com> Date: Sat, 11 Aug 2007 10:54:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Dilyan Palauzov CC: ietf-mta-filters@imc.org Subject: Re: WGLC on draft-ietf-sieve-mime-loop References: <46B6E07A.8050008@isode.com> <46B7447A.9080105@aegee.org> In-Reply-To: <46B7447A.9080105@aegee.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Dilyan Palauzov wrote: > Hello, > > > 7 Action extract_text > >> QUESTION: What do we do if the Content-Transfer-Encoding is anything >> other than 7bit? > > If it is 8bit, we take the :first number characters (not bytes), Actually 'octet' should be used, as 'character' might use one or more octets, depending on charset. > taking into account the "charset=" parameter of the Content-Type > header, when presented. If it is base64 or quoted-printable, we > convert it to 8bit and proceed as if it was 8bit. The same for binary, Agreed. > even if the result will be probably useless. (The useless results can > happen using base64, too, but the possibility is smaller) > >> :type, :subtype, :contenttype > > What is the obvious advantage of having them, compared to header > :contains ? I mean, isn't 'header :contains "Content-Type" "text/"' as > powerful, If I remember correctly, the header test doesn't know anything about header field structure, so it can match any of the Content-type parameters. > as 'header :type "Context-Type" "text"'? In addition to the above, I think this is slightly easier to understand 'header :contains "Content-Type" "text/"' > If this was discussed already on this list, could you tell me the > starting date? From owner-ietf-mta-filters@mail.imc.org Sat Aug 11 17:16:53 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7BMGmW22582 for ; Sat, 11 Aug 2007 17:16:50 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BLw8Tc012547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 14:58:08 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7BLw8Y0012546; Sat, 11 Aug 2007 14:58:08 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from narn.hozed.org (narn.hozed.org [209.234.73.39]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7BLw63Z012537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Aug 2007 14:58:07 -0700 (MST) (envelope-from hozer@hozed.org) Received: from localhost (localhost [127.0.0.1]) (uid 1000) by narn.hozed.org with local; Sat, 11 Aug 2007 16:58:06 -0500 id 0000C422.46BE30EE.000029DE Date: Sat, 11 Aug 2007 16:58:06 -0500 From: Troy Benjegerdes To: ietf-mta-filters@imc.org Subject: sieve-refuse-reject implementations? Message-ID: <20070811215806.GJ2021@narn.hozed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Does anyone have an implementation of sieve-refuse-reject that can work with Postfix, Courier-mta, or Exim? I have been using courier-mta's localmailfilter ( http://www.courier-mta.org/localmailfilter.html ) features to run spamassassin at SMTP-time via maildrop, and I'd like to try to migrate to something that uses SIEVE since I'd like to have someone other than myself be able to use SMTP-time reject. -- -------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed.org Somone asked me why I work on this free (http://www.fsf.org/philosophy/) software stuff and not get a real job. Charles Shultz had the best answer: "Why do musicians compose symphonies and poets write poems? They do it because life wouldn't have any meaning for them if they didn't. That's why I draw cartoons. It's my life." -- Charles Shultz From owner-ietf-mta-filters@mail.imc.org Sat Aug 11 19:50:16 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7C0o1W25342 for ; Sat, 11 Aug 2007 19:50:03 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C0cQJ2027484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 17:38:26 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7C0cQmx027483; Sat, 11 Aug 2007 17:38:26 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C0cO9M027475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Aug 2007 17:38:25 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IK1TK-000590-4D; Sun, 12 Aug 2007 02:38:22 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IK1TJ-0006HS-Ic; Sun, 12 Aug 2007 02:38:21 +0200 Received: from kaksi.ifi.uio.no ([129.240.65.193]) by mail-mx2.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IK1TJ-0006HL-Fd; Sun, 12 Aug 2007 02:38:21 +0200 Subject: Re: WGLC on draft-ietf-sieve-mime-loop From: Kjetil Torgrim Homme To: Alexey Melnikov Cc: Dilyan Palauzov , ietf-mta-filters@imc.org In-Reply-To: <46BD8750.5040200@isode.com> References: <46B6E07A.8050008@isode.com> <46B7447A.9080105@aegee.org> <46BD8750.5040200@isode.com> Content-Type: text/plain Date: Sun, 12 Aug 2007 02:38:15 +0200 Message-Id: <1186879095.4965.25.camel@kaksi.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.9, required=12.0, autolearn=disabled, AWL=0.142,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: DFE24077EFB3773455572370A6273637DEC8A2E7 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -48 maxlevel 200 minaction 2 bait 0 mail/h: 47 total 3198335 max/h 8345 blacklist 0 greylist 0 ratelimit 0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Sat, 2007-08-11 at 10:54 +0100, Alexey Melnikov wrote: > Dilyan Palauzov wrote: > > If it is 8bit, we take the :first number characters (not bytes), > > Actually 'octet' should be used, as 'character' might use one or more > octets, depending on charset. please, no. it's not good that you can't know if you get a garbage value, ie. a truncated UTF-8 sequence or UCS-2, Big5, Shift-JIS or any other character set encoding which uses multiple octets for a single character. 3028 (and 3028bis) already has wording which says transcoding into UTF-8 SHOULD be supported. it seems natural that this extension takes the lead of [SIEVE] section 2.7.2. I wouldn't mind it if this extension *requires* support similar to what is described in the second paragraph: [...] Implementations convert text from header fields in all charsets [MIME3] to Unicode, encoded as UTF-8, as input to the comparator (see 2.7.3). Implementations MUST be capable of converting US-ASCII, ISO-8859-1, the US-ASCII subset of ISO-8859-* character sets, and UTF-8. Text that the implementation cannot convert to Unicode for any reason MAY be treated as plain US-ASCII (including any [MIME3] syntax) or processed according to local conventions. [...] I can't see any advantage to allowing an implementation to cop out of this -- it's not a very streneous requirement, and it would cause interoperability problems if it is made a quality of implementation issue. remember that the eventual goal of IETF is to make e-mail pure UTF-8, with as little extraneous protocol as possible. we shouldn't add non-i18n aware features now. > >> :type, :subtype, :contenttype > > > > What is the obvious advantage of having them, compared to header > > :contains ? I mean, isn't 'header :contains "Content-Type" "text/"' as > > powerful, > > If I remember correctly, the header test doesn't know anything about > header field structure, so it can match any of the Content-type parameters. yes, consider Content-Type: image/jpeg; x-exif-data="context/something/other" you could use :matches (since it is an anchored search), but it would only work on the type, not the subtype. e.g. header :matches "Content-Type" "*/plain" wouldn't match Content-Type: text/plain; format="flowed" and you can't easily fix the pattern to handle it. however, I still don't see the need for all three, IMHO just :contenttype is enough, and header :matches :contenttype "Content-Type" "text/*" is as clear or maybe clearer than header :type "Content-Type" "text" I am hard pressed to find a use for the :subtype test, too. > In addition to the above, I think this is slightly easier to understand > 'header :contains "Content-Type" "text/"' oh, we agree :-) -- Kjetil T. From owner-ietf-mta-filters@mail.imc.org Sat Aug 11 20:18:32 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7C1IQW00779 for ; Sat, 11 Aug 2007 20:18:28 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C15LPM030212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2007 18:05:21 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7C15L3i030211; Sat, 11 Aug 2007 18:05:21 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7C15Jmw030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Aug 2007 18:05:21 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IK1tP-0001ej-9A; Sun, 12 Aug 2007 03:05:19 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx6.uio.no) by mail-mx6.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IK1tO-00085s-Un; Sun, 12 Aug 2007 03:05:19 +0200 Received: from kaksi.ifi.uio.no ([129.240.65.193]) by mail-mx6.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IK1tO-00083U-Ra; Sun, 12 Aug 2007 03:05:18 +0200 Subject: Re: Naming conventions for Sieve RFCs From: Kjetil Torgrim Homme To: Nigel Swinson Cc: ietf-mta-filters@imc.org In-Reply-To: <007f01c7db68$230c5140$d201a8c0@nigelhome> References: <007f01c7db68$230c5140$d201a8c0@nigelhome> Content-Type: text/plain Date: Sun, 12 Aug 2007 03:05:13 +0200 Message-Id: <1186880713.4965.39.camel@kaksi.ifi.uio.no> Mime-Version: 1.0 X-Mailer: Evolution 2.6.0 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=-4.8, required=12.0, autolearn=disabled, AWL=0.163,UIO_MAIL_IS_INTERNAL=-5) X-UiO-Scanned: 189D6C08A2CCC52F0C68B34FC2637EFA1038B30C X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -47 maxlevel 200 minaction 2 bait 0 mail/h: 10 total 3198372 max/h 8345 blacklist 0 greylist 0 ratelimit 0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Fri, 2007-08-10 at 17:03 +0100, Nigel Swinson wrote: > Did we decide on a naming convention for Sieve extensions? I don't think so. when I brought it up a couple of years ago, there wasn't much interest in such nitpicking :-) > We seem to have > either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it > would be helpful to be consistent. I agree. > Looking for a precedent from the existing RFCs we have: > > RFC3431 Sieve Extension: Relational Tests. > RFC3598 Sieve Email Filtering -- Subaddress Extension. > RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. > RFC3894 Sieve Extension: Copying Without Side Effects. > > http://www.ietf.org/html.charters/sieve-charter.html lists the other > I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has > the majority vote just now. it's odd to count unpublished drafts, IMHO. I obviously prefer the shorter "Sieve extension". But if you're looking at them, note the "Sieve notification" drafts -- they're not called "Sieve Email Filtering: mailto notification mechanism" etc. > That means we should change these if possible: > > http://tools.ietf.org/html/draft-ietf-sieve-variables > Sieve Extension: Variables I would rather not put my name on a document which uses the misspelling "email", which is actually an old name for "enamel". it should say "e-mail" or just "mail". -- Kjetil T. From owner-ietf-mta-filters@mail.imc.org Mon Aug 13 04:45:49 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7D9jbU06447 for ; Mon, 13 Aug 2007 04:45:39 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7D9Q6r6071321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 02:26:06 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7D9Q6lm071320; Mon, 13 Aug 2007 02:26:06 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7D9Q5lJ071314 for ; Mon, 13 Aug 2007 02:26:05 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 13 Aug 2007 10:26:02 +0100 Message-ID: <46BEDD40.6020009@isode.com> Date: Sun, 12 Aug 2007 11:13:20 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Nigel Swinson CC: ietf-mta-filters@imc.org Subject: Re: Naming conventions for Sieve RFCs References: <007f01c7db68$230c5140$d201a8c0@nigelhome> In-Reply-To: <007f01c7db68$230c5140$d201a8c0@nigelhome> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Nigel Swinson wrote: >Did we decide on a naming convention for Sieve extensions? > I remember we've discussed this before, but I don't remember the outcome and I am offline at the moment. >We seem to have >either "Sieve Email Filtering: ..." or "Sieve Extension: ..." and I think it >would be helpful to be consistent. Looking for a precedent from the >existing RFCs we have: > >RFC3431 Sieve Extension: Relational Tests. W. Segmuller. December 2002. > (Format: TXT=12849 bytes) (Status: PROPOSED STANDARD) > >RFC3598 Sieve Email Filtering -- Subaddress Extension. K. Murchison. > September 2003. (Format: TXT=11151 bytes) (Status: PROPOSED STANDARD) > >RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. C. > Daboo. February 2004. (Format: TXT=17436 bytes) (Status: PROPOSED > STANDARD) > >RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener. > October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD) > >http://www.ietf.org/html.charters/sieve-charter.html lists the other >I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has >the majority vote just now. That means we should change these if possible: > >http://tools.ietf.org/html/draft-ietf-sieve-variables >Sieve Extension: Variables > > Your proposal should work here. >http://tools.ietf.org/html/draft-ietf-sieve-notify-08 >Sieve Extension: Notifications > > I can change the title, but I think that: SIEVE Email Filtering Extension: Notifications is slightly more informative than: SIEVE Email Filtering: Enotify Extension (who would know that enotify is about notifications?) Opinions? >http://tools.ietf.org/html/draft-ietf-sieve-3431bis-04 >Sieve Extension: Relational Tests > > The same problem as above here: I think "Relational Tests" is more informative that "Relational Extension" From owner-ietf-mta-filters@mail.imc.org Mon Aug 13 05:52:05 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7DAq1U30376 for ; Mon, 13 Aug 2007 05:52:02 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAbp46078155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 03:37:51 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DAbp0c078154; Mon, 13 Aug 2007 03:37:51 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAboOK078148 for ; Mon, 13 Aug 2007 03:37:50 -0700 (MST) (envelope-from Nigel.Swinson@mailsite.com) Received: from nigelhome (unverified [10.42.40.207]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id ; Mon, 13 Aug 2007 03:37:45 -0700 Message-ID: <00c801c7dd95$fc551b10$d201a8c0@nigelhome> From: "Nigel Swinson" To: "Kjetil Torgrim Homme" Cc: References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <1186880713.4965.39.camel@kaksi.ifi.uio.no> Subject: Re: Naming conventions for Sieve RFCs Date: Mon, 13 Aug 2007 11:37:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > > Looking for a precedent from the existing RFCs we have: > > > > RFC3431 Sieve Extension: Relational Tests. > > RFC3598 Sieve Email Filtering -- Subaddress Extension. > > RFC3685 SIEVE Email Filtering: Spamtest and VirusTest Extensions. > > RFC3894 Sieve Extension: Copying Without Side Effects. > > > > http://www.ietf.org/html.charters/sieve-charter.html lists the other > > I-Drafts out there for Sieve and I think "Sieve Email Filtering: ..." has > > the majority vote just now. > > it's odd to count unpublished drafts, IMHO. I obviously prefer the > shorter "Sieve extension". But if you're looking at them, note the > "Sieve notification" drafts -- they're not called "Sieve Email > Filtering: mailto notification mechanism" etc. I also prefer the "Sieve Extension:" prefix. I agree the notification drafts should also have a predictable prefix, but they seem to have that already, so didn't bring it up. Ideally I'd like them to also have the same prefix as the "Sieve Extension:"s, perhaps with at additional prefix after that. However we obviously want to take care that any such prefix does not become too long. > > That means we should change these if possible: > > > > http://tools.ietf.org/html/draft-ietf-sieve-variables > > Sieve Extension: Variables > > I would rather not put my name on a document which uses the misspelling > "email", which is actually an old name for "enamel". it should say > "e-mail" or just "mail". While that might be true and I don't care much either way, it sounds like a fruitless battle. Surely "email" is so embedded in the common consciousness by now that it communicates the correct concept, and is that not the aim of words? Nigel From owner-ietf-mta-filters@mail.imc.org Mon Aug 13 05:59:44 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7DAxdU32220 for ; Mon, 13 Aug 2007 05:59:40 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAkaF2079508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 03:46:36 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DAkacL079507; Mon, 13 Aug 2007 03:46:36 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.rockliffe.com (mail.rockliffe.com [147.208.128.10]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DAkZor079499 for ; Mon, 13 Aug 2007 03:46:36 -0700 (MST) (envelope-from Nigel.Swinson@mailsite.com) Received: from nigelhome (unverified [10.42.40.207]) by mail.rockliffe.com (Rockliffe SMTPRA 8.0.2) with ESMTP id ; Mon, 13 Aug 2007 03:46:34 -0700 Message-ID: <010b01c7dd97$37ab4580$d201a8c0@nigelhome> From: "Nigel Swinson" To: "Alexey Melnikov" Cc: References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> Subject: Re: Naming conventions for Sieve RFCs Date: Mon, 13 Aug 2007 11:46:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > >http://tools.ietf.org/html/draft-ietf-sieve-variables > >Sieve Extension: Variables > > > > > Your proposal should work here. > > >http://tools.ietf.org/html/draft-ietf-sieve-notify-08 > >Sieve Extension: Notifications > > > > > I can change the title, but I think that: > SIEVE Email Filtering Extension: Notifications > > is slightly more informative than: > > SIEVE Email Filtering: Enotify Extension > > (who would know that enotify is about notifications?) > > Opinions? I'd be happy with: Sieve Email Filtering: Notifications > >http://tools.ietf.org/html/draft-ietf-sieve-3431bis-04 > >Sieve Extension: Relational Tests > > > > > The same problem as above here: I think "Relational Tests" is more > informative that "Relational Extension" I'd be happy with: Sieve Email Filtering: Relational Tests I don't care if it's SIEVE or Sieve, either, but think it better to be consistent, and it isn't consistent out there at the moment. Nigel From owner-ietf-mta-filters@mail.imc.org Mon Aug 13 08:41:49 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7DDfhU13635 for ; Mon, 13 Aug 2007 08:41:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDRwX0099658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Aug 2007 06:27:58 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7DDRwkv099657; Mon, 13 Aug 2007 06:27:58 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from pat.uio.no (pat.uio.no [129.240.10.15]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7DDRsNf099643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Aug 2007 06:27:58 -0700 (MST) (envelope-from kjetilho@ifi.uio.no) Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IKZxY-00009K-Mm; Mon, 13 Aug 2007 15:27:52 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IKZxY-0000Iy-7C; Mon, 13 Aug 2007 15:27:52 +0200 Received: from pat-gw.osl.fast.no ([217.144.235.5] helo=[192.168.3.154]) by mail-mx4.uio.no with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IKZxX-0000IH-VH; Mon, 13 Aug 2007 15:27:52 +0200 Subject: Re: Naming conventions for Sieve RFCs From: Kjetil Torgrim Homme To: Alexey Melnikov Cc: Nigel Swinson , ietf-mta-filters@imc.org In-Reply-To: <46BEDD40.6020009@isode.com> References: <007f01c7db68$230c5140$d201a8c0@nigelhome> <46BEDD40.6020009@isode.com> Content-Type: text/plain Date: Mon, 13 Aug 2007 15:27:48 +0200 Message-Id: <1187011668.15776.6.camel@oslhomkje> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-SPF-Received: X-UiO-Resend: resent X-UiO-SPF-Received: X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=12.0, autolearn=disabled, none) X-UiO-Scanned: A32973036C5B0BB17396BC3FF50D2B5F51B9F217 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 957 total 3220398 max/h 8345 blacklist 0 greylist 0 ratelimit 0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Sun, 2007-08-12 at 11:13 +0100, Alexey Melnikov wrote: > Nigel Swinson wrote: > >RFC3894 Sieve Extension: Copying Without Side Effects. J. Degener. > > October 2004. (Format: TXT=9018 bytes) (Status: PROPOSED STANDARD) > I can change the title, but I think that: > SIEVE Email Filtering Extension: Notifications > > is slightly more informative than: > > SIEVE Email Filtering: Enotify Extension > > (who would know that enotify is about notifications?) > > Opinions? I don't think it is necessary to use the capability string in the title, cf. RFC 3894 above, but you need to write it differently so as not to imply it, e.g. "Sieve Email Filtering: Extension for Notifications" as previously stated, I prefer the title stays as "Sieve Extension: Notifications". -- kind regards, Kjetil T. Homme sysadmin R&D, FAST From owner-ietf-mta-filters@mail.imc.org Fri Aug 17 16:38:16 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7HLcD908187 for ; Fri, 17 Aug 2007 16:38:15 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLNWPw093862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 14:23:32 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HLNWuo093861; Fri, 17 Aug 2007 14:23:32 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLNU0U093854 for ; Fri, 17 Aug 2007 14:23:31 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 17 Aug 2007 22:23:28 +0100 Message-ID: <46C61205.7010809@isode.com> Date: Fri, 17 Aug 2007 22:24:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Sam Hartman , Lisa Dusseault CC: Philip Guenther , ietf-mta-filters@imc.org Subject: Suggested changes to address Sam's DISCUSS on draft-ietf-sieve-3028bis-12.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean I've suggested the following changes to Sam and Philip and they seemed to be Ok with them. I am resending them to the mailing list. ============= I suggest to do the following changes to section 7 (they include some extra minor changes which I've noticed while checking RFC 4288 which replaced RFC 2048): OLD: The [MIME] type for a Sieve script is "application/sieve". The registration of this type for RFC 2048 requirements is updated as ^^^^ follows: Subject: Registration of MIME media type application/sieve MIME media type name: application ^^^^^^^^^^^^^^^ MIME subtype name: sieve ^^^^^^^^^^^^ NEW: The [MIME] type for a Sieve script is "application/sieve". The registration of this type for RFC 4288 requirements is updated as ^^^^ follows: Subject: Registration of MIME media type application/sieve Type name: application ^^^^ Subtype name: sieve ^^^^^^^ Replace OLD: Author/Change controller: See Editor information in this RFC. with NEW: Author: See Editor information in this RFC. Change controller: IESG Does this work for everybody? From owner-ietf-mta-filters@mail.imc.org Fri Aug 17 16:45:38 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7HLjW910041 for ; Fri, 17 Aug 2007 16:45:34 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLXRbM095702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 14:33:27 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HLXRbn095701; Fri, 17 Aug 2007 14:33:27 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HLXQYX095693 for ; Fri, 17 Aug 2007 14:33:26 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 17 Aug 2007 22:33:23 +0100 Message-ID: <46C61458.7090903@isode.com> Date: Fri, 17 Aug 2007 22:34:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cullen Jennings , Lisa Dusseault , Philip Guenther CC: ietf-mta-filters@imc.org, iesg@ietf.org Subject: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Cullen, does the following address your DISCUSS? ============================= In section 4.2, last paragraph: OLD: Implementations SHOULD take measures to implement loop control, possibly including adding headers to the message or counting Received headers. If an implementation detects a loop, it causes an error. NEW: Implementations SHOULD take measures to implement loop control, possibly including adding headers to the message or counting Received headers as specified in section 6.2 of [SMTP]. If an implementation detects a loop, it causes an error. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Add to the end of section 4.2 two new paragraphs: Implementations SHOULD provide means of limiting the number of redirects a Sieve script can perform. Implementations MAY ignore a redirect action silently due to policy reasons. For example, an implementation MAY choose not to redirect to an address that is known to be undeliverable. In section 10, 2nd paragraph: OLD: It is equally important that implementations sanity-check the user's ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ scripts, and not allow users to create on-demand mailbombs. For ^^^^^^^^^ instance, an implementation that allows a user to redirect a message multiple times might also allow a user to create a mailbomb triggered by mail from a specific user. Site- or implementation-defined limits on actions are useful for this. NEW: Implementations SHOULD sanity-check the user's ^^^^^^ scripts. Implementations SHOULD NOT allow users to create on-demand mailbombs. For ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ instance, an implementation that allows a user to redirect a message multiple times might also allow a user to create a mailbomb triggered by mail from a specific user. Site- or implementation-defined limits on actions are useful for this. ============================ Comments? The example that follows "MAY ignore redirect due to policy" seems to be non-related to policy. Is extra wordsmithing needed here? From owner-ietf-mta-filters@mail.imc.org Fri Aug 17 17:45:19 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7HMjB924630 for ; Fri, 17 Aug 2007 17:45:13 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMV5UE003199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 15:31:05 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HMV57a003198; Fri, 17 Aug 2007 15:31:05 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMV3GP003191 for ; Fri, 17 Aug 2007 15:31:04 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MK9N01N534007W1W@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 17 Aug 2007 15:30:54 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MK9IOPPAIO00005F@mauve.mrochek.com>; Fri, 17 Aug 2007 15:30:50 -0700 (PDT) Cc: Sam Hartman , Lisa Dusseault , Philip Guenther , ietf-mta-filters@imc.org Message-id: <01MK9MZZIAHA00005F@mauve.mrochek.com> Date: Fri, 17 Aug 2007 15:30:21 -0700 (PDT) From: Ned Freed Subject: Re: Suggested changes to address Sam's DISCUSS on draft-ietf-sieve-3028bis-12.txt In-reply-to: "Your message dated Fri, 17 Aug 2007 22:24:21 +0100" <46C61205.7010809@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <46C61205.7010809@isode.com> To: Alexey Melnikov DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1187389853; h=Date: From:Subject:MIME-version:Content-type; b=W8cQV/jf0M4GJBqJBYeMuE2X8 BBNHPjR8DmeBJWLuFPdFNYk9Lpx8Va5Y/jgN7E6lCX6Ri3qWH0VsXoJgw+Sxw== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > I've suggested the following changes to Sam and Philip and they seemed > to be Ok with them. I am resending them to the mailing list. > ============= > I suggest to do the following changes to section 7 (they include some > extra minor changes which I've noticed while checking RFC 4288 which > replaced RFC 2048): > OLD: > The [MIME] type for a Sieve script is "application/sieve". > The registration of this type for RFC 2048 requirements is updated as > ^^^^ > follows: > Subject: Registration of MIME media type application/sieve > MIME media type name: application > ^^^^^^^^^^^^^^^ > MIME subtype name: sieve > ^^^^^^^^^^^^ > NEW: > The [MIME] type for a Sieve script is "application/sieve". > The registration of this type for RFC 4288 requirements is updated as > ^^^^ > follows: > Subject: Registration of MIME media type application/sieve > Type name: application > ^^^^ > Subtype name: sieve > ^^^^^^^ > Replace > OLD: > Author/Change controller: > See Editor information in this RFC. > with > NEW: > Author: > See Editor information in this RFC. > Change controller: > IESG > Does this work for everybody? Looks fine to me. Ned From owner-ietf-mta-filters@mail.imc.org Fri Aug 17 18:01:26 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7HN1M928444 for ; Fri, 17 Aug 2007 18:01:24 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMnGlK004742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Aug 2007 15:49:16 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7HMnGIr004741; Fri, 17 Aug 2007 15:49:16 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mauve.mrochek.com (dsl-66-59-230-40.static.linkline.com [66.59.230.40]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7HMnEe6004733 for ; Fri, 17 Aug 2007 15:49:15 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MK9NMP4W4G006W5Z@mauve.mrochek.com> for ietf-mta-filters@imc.org; Fri, 17 Aug 2007 15:49:10 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01MK9IOPPAIO00005F@mauve.mrochek.com>; Fri, 17 Aug 2007 15:49:05 -0700 (PDT) Cc: Cullen Jennings , Lisa Dusseault , Philip Guenther , ietf-mta-filters@imc.org, iesg@ietf.org Message-id: <01MK9NMMZZHY00005F@mauve.mrochek.com> Date: Fri, 17 Aug 2007 15:31:14 -0700 (PDT) From: Ned Freed Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt In-reply-to: "Your message dated Fri, 17 Aug 2007 22:34:16 +0100" <46C61458.7090903@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <46C61458.7090903@isode.com> To: Alexey Melnikov DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1187390949; h=Date: From:Subject:MIME-version:Content-type; b=fTFoJxZvrAT3YuGqXxNWmKjFf +ZhMPkwEO8k4KsOEBnfyf0nb8IubZWwZ+/tebrwmgnzvl7VJCaqQR1aza42aw== Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean > Cullen, does the following address your DISCUSS? > ============================= > In section 4.2, last paragraph: > OLD: > Implementations SHOULD take measures to implement loop control, > possibly including adding headers to the message or counting Received > headers. If an implementation detects a loop, it causes an error. > NEW: > Implementations SHOULD take measures to implement loop control, > possibly including adding headers to the message or counting Received > headers as specified in section 6.2 of [SMTP]. If an implementation > detects a loop, it causes an error. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I can live with this, but I have to say I see it as Mostly Harmless: The previous text already prohibited removal of Received: fields so existing loop control mechanisms based on Received: line counting seem sufficient. I do note that neither the original text nor the new text are even close to sufifcient ot deal with looping issues pertaining to the notify extension. But we can deal with that issue in the notify specificaitons. > Add to the end of section 4.2 two new paragraphs: > Implementations SHOULD provide means of limiting the number of redirects a > Sieve script can perform. Given that this is essentially the fix I recommended I have no problem with it ;-) > Implementations MAY ignore a redirect action silently due to policy reasons. > For example, an implementation MAY choose not to redirect to an address that > is known to be undeliverable. This, OTOH, is not an acceptable change. In particular, it is OK to ignore a redirect if and only if such an ignored action no longer cancels the implicit keep. (A redirect that's ignored and which cancels the implicit keep could easily result in silent loss of mail.) I suggest adding one additional sentence: An ignored redirect MUST NOT cancel the implicit keep. > In section 10, 2nd paragraph: > OLD: > It is equally important that implementations sanity-check the user's > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > scripts, and not allow users to create on-demand mailbombs. For > ^^^^^^^^^ > instance, an implementation that allows a user to redirect a message > multiple times might also allow a user to create a mailbomb triggered > by mail from a specific user. Site- or implementation-defined limits > on actions are useful for this. > NEW: > Implementations SHOULD sanity-check the user's > ^^^^^^ > scripts. Implementations SHOULD NOT allow users to create on-demand > mailbombs. For > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > instance, an implementation that allows a user to redirect a message > multiple times might also allow a user to create a mailbomb triggered > by mail from a specific user. Site- or implementation-defined limits > on actions are useful for this. I have no problem with this change. > The example that follows "MAY ignore redirect due to policy" seems to be > non-related to policy. > Is extra wordsmithing needed here? I don't understand the point. You're proposing adding this text to the end of section 4.2, right? The only example in that section is the script that redirects everything but that would seem to appear in the middle rather than after this new text. What am I missing? Ned From owner-ietf-mta-filters@mail.imc.org Sat Aug 18 12:36:50 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7IHaj925546 for ; Sat, 18 Aug 2007 12:36:47 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7IHNAeV010410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Aug 2007 10:23:10 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7IHNAOu010409; Sat, 18 Aug 2007 10:23:10 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7IHMmHa010390 for ; Sat, 18 Aug 2007 10:23:09 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 18 Aug 2007 18:22:45 +0100 Message-ID: <46C72B19.2070408@isode.com> Date: Sat, 18 Aug 2007 18:23:37 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Ned Freed CC: Cullen Jennings , Lisa Dusseault , Philip Guenther , ietf-mta-filters@imc.org, iesg@ietf.org Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt References: <46C61458.7090903@isode.com> <01MK9NMMZZHY00005F@mauve.mrochek.com> In-Reply-To: <01MK9NMMZZHY00005F@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Ned Freed wrote: >> Cullen, does the following address your DISCUSS? > >> ============================= >> In section 4.2, last paragraph: > >> OLD: >> Implementations SHOULD take measures to implement loop control, >> possibly including adding headers to the message or counting Received >> headers. If an implementation detects a loop, it causes an error. >> NEW: >> Implementations SHOULD take measures to implement loop control, >> possibly including adding headers to the message or counting Received >> headers as specified in section 6.2 of [SMTP]. If an implementation > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> detects a loop, it causes an error. > > I can live with this, but I have to say I see it as Mostly Harmless: The > previous text already prohibited removal of Received: fields so existing > loop control mechanisms based on Received: line counting seem > sufficient. Cullen wanted a specific reference. > I do note that neither the original text nor the new text are even > close to > sufifcient ot deal with looping issues pertaining to the notify > extension. But > we can deal with that issue in the notify specificaitons. Indeed. >> Add to the end of section 4.2 two new paragraphs: > >> Implementations SHOULD provide means of limiting the number of >> redirects a >> Sieve script can perform. > > Given that this is essentially the fix I recommended I have no problem > with it > ;-) Yes, this is exactly what you've suggested. >> Implementations MAY ignore a redirect action silently due to policy >> reasons. >> For example, an implementation MAY choose not to redirect to an >> address that >> is known to be undeliverable. > > This, OTOH, is not an acceptable change. In particular, it is OK to > ignore a > redirect if and only if such an ignored action no longer cancels the > implicit > keep. (A redirect that's ignored and which cancels the implicit keep > could > easily result in silent loss of mail.) > > I suggest adding one additional sentence: > > An ignored redirect MUST NOT cancel the implicit keep. Good point. >> In section 10, 2nd paragraph: > >> OLD: >> It is equally important that implementations sanity-check the user's >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> scripts, and not allow users to create on-demand mailbombs. For >> ^^^^^^^^^ >> instance, an implementation that allows a user to redirect a message >> multiple times might also allow a user to create a mailbomb triggered >> by mail from a specific user. Site- or implementation-defined limits >> on actions are useful for this. > >> NEW: >> Implementations SHOULD sanity-check the user's >> ^^^^^^ >> scripts. Implementations SHOULD NOT allow users to create on-demand >> mailbombs. For >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> instance, an implementation that allows a user to redirect a message >> multiple times might also allow a user to create a mailbomb triggered >> by mail from a specific user. Site- or implementation-defined limits >> on actions are useful for this. > > I have no problem with this change. > >> The example that follows "MAY ignore redirect due to policy" seems to be >> non-related to policy. >> Is extra wordsmithing needed here? > > I don't understand the point. You're proposing adding this text to the > end of section 4.2, right? The only example in that section is the > script that redirects everything but that would seem to appear in the > middle rather than after this new text. > > What am I missing? Ignore that, I don't remember which example I was talking about ;-) (It is problematic to review RFC editor notes that were done a couple of months ago) From owner-ietf-mta-filters@mail.imc.org Mon Aug 20 17:43:12 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7KMh6911435 for ; Mon, 20 Aug 2007 17:43:08 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7KMP73O071093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2007 15:25:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7KMP7jT071092; Mon, 20 Aug 2007 15:25:07 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from shell.mv.net (osmium.mv.net [199.125.85.152]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id l7KMP5Xl071086 for ; Mon, 20 Aug 2007 15:25:06 -0700 (MST) (envelope-from mem@mv.mv.com) Received: (qmail 71930 invoked by uid 101); 20 Aug 2007 18:25:04 -0400 From: "Mark E. Mallett" Date: Mon, 20 Aug 2007 18:25:04 -0400 To: Alexey Melnikov Cc: ietf-mta-filters@imc.org Subject: Re: WGLC on draft-ietf-sieve-mime-loop Message-ID: <20070820222504.GA66409@osmium.mv.net> References: <46B6E07A.8050008@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46B6E07A.8050008@isode.com> User-Agent: Mutt/1.4.2.1i Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean On Mon, Aug 06, 2007 at 09:48:58AM +0100, Alexey Melnikov wrote: > > Hi, > > This message officially starts the Sieve Working Group Last Call for > the following document: > > SIEVE Email Filtering: MIME part Tests, Iteration, Replacement and > Enclosure > > > The Working Group Last Call for this document starts on August 6th and will > end on August 20th. Hi, I had intended to get some comments out before the last day (i.e., before today) but haven't managed to organize my thoughts well enough. I'd like to get them out to the list in the next day or two. Regardless, I don't think this is ready for last call yet. mm From owner-ietf-mta-filters@mail.imc.org Tue Aug 21 08:00:48 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7LD0h908236 for ; Tue, 21 Aug 2007 08:00:45 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LCeqwY053201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2007 05:40:52 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7LCeqZr053200; Tue, 21 Aug 2007 05:40:52 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from mail.serendipity.cx (serendipity.palo-alto.ca.us [66.92.2.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7LCepaX053193 for ; Tue, 21 Aug 2007 05:40:51 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from [192.168.1.146] (localhost [127.0.0.1]) by mail.serendipity.cx (Postfix) with ESMTP id EF84230CF; Tue, 21 Aug 2007 05:44:56 -0700 (PDT) Subject: Notify options and URI encoding From: Aaron Stone To: Alexey.Melnikov@isode.com, leiba@watson.ibm.com Cc: ietf-mta-filters@imc.org Content-Type: text/plain Date: Tue, 21 Aug 2007 05:41:57 -0700 Message-Id: <1187700118.21144.48.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.2 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Hello notifiers, I re-read notify-08, and it jumped out at me that :options takes a stringlist argument! I had it in mind that it was a single string, so both :options and the method itself were equally good places for encoded parameters. I had a significant concern about the interpretation of something like: notify "method:whatever&subject=foo ${evilvar}"; where ${evilvar} might come directly from the message and might contain nefarious data. That concern has been reflected in the draft with the new :encodeurl variables parameter. But it's sort of a hack because we're looking at encoding in the first place. I think that encoded parameters on the method name should be prohibited outright. All ad-hoc parameters should arrive via :options. That's what it's there for, right? notify :options "subject=Hello this is the Subject" "mailto:foo@bar"; is much better than notify "mailto:foo@bar&subject=Hello%20this%20is%20the%20Subject"; Example 3 is particularly bad, starting with this variable: set "notif_method" "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail"; I think this should be re-written to show that :options is a string list and to reflect that encoding is done by the implementation: set "notif_method" "xmpp:tim@example.com?message" set "notif_subject" "SIEVE" set "notif_body" "You've got mail" ... tests in the example that override the defaults ... notify :options [ "subject=${notif_subject}", "body=${notif_body}" ] "${notif_method}"; Suggested new text in the description of :options, Section 3.5: Values may be URI-encoded and may be expanded from variables. Therefore, notification methods MUST NOT perform full URI-decoding of each option string, lest untrusted data contained in the variable become indistinguishable from user-specified data. Security Considerations, this is from -08: Implementations that construct URIs internally from various notify parameters MUST make sure that all components of such URIs are properly percent-encoded (see [URI]). In particular this applies to values of the :from and the :message tagged arguments and may apply to the :options values. I think this is good, and we can drop Section 6, Modifier encodeurl, too, as :encodeurl is not needed if the process for assembling a URI is something like this (psuedo-perl): sub make_notify_uri( method, from, importance, options ) return error unless sanity_check( method ) uri = concat( method, "&from=", urlencode( from ) ) uri = concat( uri, "&importance=", urlencode( importance ) ) for each options next unless (key, value) =~ /([:alnum:])=(.*)/ uri = concat( uri, "&", key, "=", urlencode( value ) ) The two important factors here are disallowing encoded methods and being careful in how the option strings are split. I think that covers all of the potential encoding holes for passing data through. Aaron From owner-ietf-mta-filters@mail.imc.org Fri Aug 24 17:58:12 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7OMw5I11771 for ; Fri, 24 Aug 2007 17:58:10 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OMiA1V004849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Aug 2007 15:44:10 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7OMiA2K004848; Fri, 24 Aug 2007 15:44:10 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7OMi8nt004842 for ; Fri, 24 Aug 2007 15:44:09 -0700 (MST) (envelope-from fluffy@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2007 15:44:08 -0700 X-IronPort-AV: i="4.19,305,1183359600"; d="scan'208"; a="172691905:sNHT51170661" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7OMi8N7006165; Fri, 24 Aug 2007 15:44:08 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id l7OMhvYb011232; Fri, 24 Aug 2007 22:43:58 GMT In-Reply-To: <46C61458.7090903@isode.com> References: <46C61458.7090903@isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Lisa Dusseault , Philip Guenther , ietf-mta-filters@imc.org, iesg@ietf.org Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt Date: Fri, 24 Aug 2007 15:42:36 -0700 To: Alexey Melnikov X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2521; t=1187995448; x=1188859448; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Suggested=20changes=20to=20address=20Cullen's=20DISCU SS=20on=20draft-ietf-sieve-3028bis-12.txt |Sender:=20; bh=SnGbWBfB5kK8c1wMJ6XDvouZ5n6rVeDEstZgoD226kI=; b=cjSOgND38K+DpG+hqXOo5gyNMr0wsYTbIR3UIEAffXd4ny5W5ZeHa+/w5WCjMWUnGH2cPkB4 0dl4b/O6sNpyEtLsIZk3PaydENoNbO7/FGc9oqiqjrrq58ul0Epw1EzP; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean I don't think that is really implementable advice - it basically wishes the problem away. More inline ... On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote: > Cullen, does the following address your DISCUSS? > > ============================= > In section 4.2, last paragraph: > > OLD: > Implementations SHOULD take measures to implement loop control, > possibly including adding headers to the message or counting Received > headers. If an implementation detects a loop, it causes an error. > NEW: > Implementations SHOULD take measures to implement loop control, > possibly including adding headers to the message or counting Received > headers as specified in section 6.2 of [SMTP]. If an > implementation detects a loop, it causes an error. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Add to the end of section 4.2 two new paragraphs: > > Implementations SHOULD provide means of limiting the number of > redirects a > Sieve script can perform. Well if it was the number of redirects SHOULD be limited to one it would do it but as it is - not sure I see how it helps. > > Implementations MAY ignore a redirect action silently due to > policy reasons. > For example, an implementation MAY choose not to redirect to an > address that > is known to be undeliverable. > > > In section 10, 2nd paragraph: > > OLD: > It is equally important that implementations sanity-check the user's > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > scripts, and not allow users to create on-demand mailbombs. For > ^^^^^^^^^ > instance, an implementation that allows a user to redirect a message > multiple times might also allow a user to create a mailbomb triggered > by mail from a specific user. Site- or implementation-defined limits > on actions are useful for this. > > NEW: > Implementations SHOULD sanity-check the user's > ^^^^^^ > scripts. Implementations SHOULD NOT allow users to create on- > demand mailbombs. For > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > instance, an implementation that allows a user to redirect a message > multiple times might also allow a user to create a mailbomb triggered > by mail from a specific user. Site- or implementation-defined limits > on actions are useful for this. > > ============================ > Comments? > > The example that follows "MAY ignore redirect due to policy" seems > to be non-related to policy. > Is extra wordsmithing needed here? > From owner-ietf-mta-filters@mail.imc.org Sat Aug 25 11:52:29 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7PGqNc15870 for ; Sat, 25 Aug 2007 11:52:25 -0500 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGaY7l080967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Aug 2007 09:36:34 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id l7PGaYw3080966; Sat, 25 Aug 2007 09:36:34 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-mta-filters@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l7PGaYsQ080960 for ; Sat, 25 Aug 2007 09:36:34 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 25 Aug 2007 17:36:32 +0100 Message-ID: <46D05AC1.6090905@isode.com> Date: Sat, 25 Aug 2007 17:37:21 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Cullen Jennings CC: Lisa Dusseault , Philip Guenther , ietf-mta-filters@imc.org, iesg@ietf.org Subject: Re: Suggested changes to address Cullen's DISCUSS on draft-ietf-sieve-3028bis-12.txt References: <46C61458.7090903@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: X-mallorn-MailScanner-Information: Please contact the ISP for more information X-mallorn-MailScanner: Found to be clean Cullen Jennings wrote: > I don't think that is really implementable advice - it basically > wishes the problem away. It is implementable, it applies to UIs and admin tools and many implementations already follow it. > More inline ... > On Aug 17, 2007, at 2:34 PM, Alexey Melnikov wrote: > >> Cullen, does the following address your DISCUSS? >> >> ============================= >> In section 4.2, last paragraph: >> >> OLD: >> Implementations SHOULD take measures to implement loop control, >> possibly including adding headers to the message or counting Received >> headers. If an implementation detects a loop, it causes an error. >> NEW: >> Implementations SHOULD take measures to implement loop control, >> possibly including adding headers to the message or counting Received >> headers as specified in section 6.2 of [SMTP]. If an >> implementation detects a loop, it causes an error. >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> Add to the end of section 4.2 two new paragraphs: >> >> Implementations SHOULD provide means of limiting the number of >> redirects a >> Sieve script can perform. > > Well if it was the number of redirects SHOULD be limited to one it > would do it but as it is - not sure I see how it helps. Cullen, I told you before, there is very strong WG consensus to allow implementations to use more than one. Please see and . Now, if you have another suggestion how to address your issue, I would like to hear it. From owner-ietf-mta-filters@mail.imc.org Sat Aug 25 11:53:10 2007 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on lorien.mallorn.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.7 X-Envelope-From: owner-ietf-mta-filters@mail.imc.org X-Envelope-To: Return-Path: Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by lorien.mallorn.com (8.11.7/8.11.7) with ESMTP id l7PGr6c16332 for ; Sat, 25 Aug 2007 11:53:08 -0500 Received: from balder-227.pr