From owner-ietf-mta-filters@mail.imc.org Tue Apr 7 06:49:33 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30E7A3A69A3 for ; Tue, 7 Apr 2009 06:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvCEQwnh2foe for ; Tue, 7 Apr 2009 06:49:32 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 279B03A68EE for ; Tue, 7 Apr 2009 06:49:28 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37DYg99096266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 06:34:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n37DYgGP096265; Tue, 7 Apr 2009 06:34:42 -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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37DYU66096243 for ; Tue, 7 Apr 2009 06:34:41 -0700 (MST) (envelope-from arnt@oryx.com) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 190D32E25F; Tue, 7 Apr 2009 15:34:27 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1239111266-53296-53284/6/15 (2 recipients); Tue, 7 Apr 2009 15:34:26 +0200 Message-Id: Date: Tue, 7 Apr 2009 15:34:45 +0200 From: Arnt Gulbrandsen To: MTA filtering mailing list Subject: notify and valid_notify_method Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Supposed to return true if all exist and are valid and supported and generally polished, and false if at least one has some imperfection. But what if the list is empty? Sounds like a degenerate true, agreed? Arnt From owner-ietf-mta-filters@mail.imc.org Thu Apr 9 01:26:57 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9B53A6AFF for ; Thu, 9 Apr 2009 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOsNo5TzCjoD for ; Thu, 9 Apr 2009 01:26:56 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 455563A67DB for ; Thu, 9 Apr 2009 01:26:55 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n398GkHF090988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 01:16:47 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n398Gkoi090987; Thu, 9 Apr 2009 01:16:46 -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-bw0-f176.google.com (mail-bw0-f176.google.com [209.85.218.176]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n398GiGf090978 for ; Thu, 9 Apr 2009 01:16:45 -0700 (MST) (envelope-from robertburrelldonkin@gmail.com) Received: by bwz24 with SMTP id 24so471154bwz.10 for ; Thu, 09 Apr 2009 01:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=LjVnrpmZCwg3umIH2ksk128nSDMQdCHunlAgklVqtu0=; b=iASNyzahI+R8/2cTba/xy8QTdwynGX9Opphd47mu3fWtZkwoHZm68fRMRHZFxm7a1M F5xkSbCAv1SiK3oaI2tZWoi8iWXiLxNoVSWD2E/xs81BZvC/pHY0Q8BPKeRPn3dvI7Y/ H7rNlfE7OWUXggsrYTeo6ZgqZvAuGJwHdv+GQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=nA7FXPJb+F/t7QSvTIGmjipBhyFF6/027qU2pMSWiEMhLGvxKuh7Cnz3KjFADmza/E 9LuDL1jl2T7qsfgeEbddV253zPFOVgTuxDxZVyQii7IRwh+3i5tyRbXveKnNngqzlWo7 8as71J5ErVec+h6wbXzz3dww5HWVsEOAFFWMM= MIME-Version: 1.0 Received: by 10.204.113.203 with SMTP id b11mr1951159bkq.109.1239265003832; Thu, 09 Apr 2009 01:16:43 -0700 (PDT) Date: Thu, 9 Apr 2009 09:16:43 +0100 Message-ID: Subject: [sieve-in-xml] Example Scripts For Integration Testing From: Robert Burrell Donkin To: MTA filtering mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: i'm much happier with the current sieve-in-xml draft. we hope to ship JSieve soon with experimental preview partial support with the hope that usage by developers may help to understand whether any issues have been missed, with a complete implementation would be targetted for the next release. however, to confidently ship a library claiming full support, a reasonably large and fully debugged corpus of integration tests is needed: basically, example sieve scripts together with corresponding sieve-in-xml documents. IMO this is the sort of data which is usually best developed and debugged collectively. from the sieve working group charter:
(5) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status.
as i read this, a collection of example sieve scripts and sieve-in-xml documents is out of scope for this group (hopefully people will jump in if my reading is incorrect) so, i was wondering whether there is any interest from members of the group in collaborating offshore (http://code.google.com, say) on creating and debugging such a corpus as an open source project under a very permissive license (MIT, say), or whether there are any other good ways that such a corpus could be created and made freely available - robert From owner-ietf-mta-filters@mail.imc.org Fri Apr 10 16:50:02 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9A228C105 for ; Fri, 10 Apr 2009 16:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiUOVdXhwZ+c for ; Fri, 10 Apr 2009 16:50:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8C6A53A6AEA for ; Fri, 10 Apr 2009 16:50:01 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ANeL7u044095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 16:40:21 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3ANeLN8044094; Fri, 10 Apr 2009 16:40: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 cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ANe89f044065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 10 Apr 2009 16:40:20 -0700 (MST) (envelope-from stephan@rename-it.nl) Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LsQKC-00014g-Qz for ietf-mta-filters@imc.org; Sat, 11 Apr 2009 01:39:56 +0200 Message-ID: <49DFD8CE.6020306@rename-it.nl> Date: Sat, 11 Apr 2009 01:39:58 +0200 From: Stephan Bosch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIEVE Subject: Questions and remarks on draft-ietf-sieve-include-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-VirusScan: Found to be clean X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.575, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.42, BAYES_00 -2.60) X-RenameIT-MailScanner-From: stephan@rename-it.nl Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, First of all, I am very glad that the work on the specification is being continued now. This week I quickly updated my implementation to match the new specification. Merging import and export into a single global command is a good choice. The use of a global variable namespace is also a good idea (but I did not implement that yet). During implementation I collected some remarks and questions: - Where the ManageSieve protocol specifies what characters are allowed for a script name, the include extension for the Sieve language does not. Would it be useful to adopt the same limitations? Especially things like '/' can cause problems. - For the global command I would expect text stating that the variables extension is required when it is used. - The global command is required to follow 'require' or another global command. I am worried what happens when other extensions have commands with similar requirements. Shouldn't we account for this eventuality? - Are there any special security implications for using variables in the value argument in the include command, i.e. to include a script specified by a variable? Is that even (intended to be) allowed? - The scope of the :once modifier could be a bit confusing. I am assuming it holds for the whole Sieve execution and not only for the identical include commands within the current script. - Take a good look at the examples: they have small typos and syntax problems: * page 6; spam_tests: reject command has mandatory message argument * page 7; spam_tests: reject command has mandatory message argument * page 8; active script: test-mailbox is not a valid variable name * page 8; active script: missing require for relational extension * page 9; active scropt: :count match type needs an argument, e.g. "eq" * page 9; active script: "spam-${test}; <- missing " Please let me know what you think. Regards, -- Stephan Bosch stephan@rename-it.nl From owner-ietf-mta-filters@mail.imc.org Fri Apr 10 17:48:52 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83CFB3A6889 for ; Fri, 10 Apr 2009 17:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1okcrFyenO3F for ; Fri, 10 Apr 2009 17:48:51 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3FBE13A689A for ; Fri, 10 Apr 2009 17:48:50 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0aBGd047273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 17:36:11 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B0aBHX047272; Fri, 10 Apr 2009 17:36:11 -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.14.2/8.14.2) with ESMTP id n3B0a0W5047249 for ; Fri, 10 Apr 2009 17:36:10 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.cx (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with ESMTP id 1203F2936; Fri, 10 Apr 2009 17:37:39 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 10 Apr 2009 17:37:39 -0700 From: Aaron Stone To: Stephan Bosch Cc: SIEVE Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt In-Reply-To: <49DFD8CE.6020306@rename-it.nl> References: <49DFD8CE.6020306@rename-it.nl> Message-ID: X-Sender: aaron@serendipity.cx User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for your comments. I'd been preparing to send an email to the list announcing the changes and requesting feedback. You've touched on all the good points. So let's run with this thread! On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch wrote: > Hi, > > First of all, I am very glad that the work on the specification is being > continued now. This week I quickly updated my implementation to match > the new specification. Merging import and export into a single global > command is a good choice. The use of a global variable namespace is also > a good idea (but I did not implement that yet). I actually wonder if we should drop the global keyword and rely on namespaces entirely. > During implementation I collected some remarks and questions: > > - Where the ManageSieve protocol specifies what characters are allowed > for a script name, the include extension for the Sieve language does > not. Would it be useful to adopt the same limitations? Especially things > like '/' can cause problems. Good suggestion. I think this makes sense to give a consistent opinion on what script names should look like, but on the other hand, perhaps it's possible that someone isn't using ManageSieve but IS using include and might need to get at weird names? Do we care in that case? > - For the global command I would expect text stating that the variables > extension is required when it is used. Will add. > - The global command is required to follow 'require' or another global > command. I am worried what happens when other extensions have commands > with similar requirements. Shouldn't we account for this eventuality? I don't like this restriction anyways. Any objection to lifting it? > - Are there any special security implications for using variables in the > value argument in the include command, i.e. to include a script > specified by a variable? Is that even (intended to be) allowed? Oh, that's a good question. That'd be an easy vector for contamination of email contents into a filesystem request. Can we reasonably place such a restriction, though? I'd hate to force implementations to special-case their string expansions. > - The scope of the :once modifier could be a bit confusing. I am > assuming it holds for the whole Sieve execution and not only for the > identical include commands within the current script. Correct. Could you suggest how I might clarify that it's the whole execution? I feel like I'm missing the right word for being inside one file vs. being inside one delivery/execution instance. > - Take a good look at the examples: they have small typos and syntax > problems: > * page 6; spam_tests: reject command has mandatory message argument > * page 7; spam_tests: reject command has mandatory message argument > * page 8; active script: test-mailbox is not a valid variable name > * page 8; active script: missing require for relational extension > * page 9; active scropt: :count match type needs an argument, e.g. > "eq" > * page 9; active script: "spam-${test}; <- missing " Will correct these. > Please let me know what you think. Thanks! Aaron From owner-ietf-mta-filters@mail.imc.org Sat Apr 11 01:16:02 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170193A6807 for ; Sat, 11 Apr 2009 01:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tMBVJSUt6D2 for ; Sat, 11 Apr 2009 01:16:01 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7C3A33A67CC for ; Sat, 11 Apr 2009 01:16:00 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B82rrg066106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 01:02:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B82r4M066105; Sat, 11 Apr 2009 01:02:53 -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 cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B82dkc066094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 11 Apr 2009 01:02:52 -0700 (MST) (envelope-from stephan@rename-it.nl) Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LsYAP-0000dR-Py; Sat, 11 Apr 2009 10:02:21 +0200 Message-ID: <49E04E83.20001@rename-it.nl> Date: Sat, 11 Apr 2009 10:02:11 +0200 From: Stephan Bosch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Aaron Stone CC: SIEVE Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt References: <49DFD8CE.6020306@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-VirusScan: Found to be clean X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.581, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.42, BAYES_00 -2.60) X-RenameIT-MailScanner-From: stephan@rename-it.nl Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Aaron, Aaron Stone wrote: > Thanks for your comments. I'd been preparing to send an email to the list > announcing the changes and requesting feedback. You've touched on all the > good points. So let's run with this thread! > > On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch > wrote: >> First of all, I am very glad that the work on the specification is being >> continued now. This week I quickly updated my implementation to match >> the new specification. Merging import and export into a single global >> command is a good choice. The use of a global variable namespace is also >> a good idea (but I did not implement that yet). > > I actually wonder if we should drop the global keyword and rely on > namespaces entirely. The global namespace has one disadvantage: it makes all global variable names longer ('global.*'). Especially when a variable is used often in a script, this may become tedious. Using the global command, it is possible to pull global variables into the script namespace, which is convenient in such situations. I guess it would be best to support both methods of accessing global variables (and to even allow mixing these freely). >> - Where the ManageSieve protocol specifies what characters are allowed >> for a script name, the include extension for the Sieve language does >> not. Would it be useful to adopt the same limitations? Especially things >> like '/' can cause problems. > > Good suggestion. I think this makes sense to give a consistent opinion on > what script names should look like, but on the other hand, perhaps it's > possible that someone isn't using ManageSieve but IS using include and > might need to get at weird names? Do we care in that case? You can also make it a recommendation. As long as implementers know that there is some consensus about what a script name is supposed to be and that script names should not be mapped directly to files for security reasons. >> - The global command is required to follow 'require' or another global >> command. I am worried what happens when other extensions have commands >> with similar requirements. Shouldn't we account for this eventuality? > I don't like this restriction anyways. Any objection to lifting it? Hmm, interesting suggestion. The main implication of this is that the inclusion of global variables into the script namespace can become conditional, i.e. when it is placed into an if statement. I don't know whether this is desirable. You could also state that the global command needs to be placed after require commands or any command that also needs to be placed directly below the require commands (choose better wording though). This implies no ordering between the commands that follow the require section, avoiding problems with future commands with similar needs. >> - Are there any special security implications for using variables in the >> value argument in the include command, i.e. to include a script >> specified by a variable? Is that even (intended to be) allowed? > > Oh, that's a good question. That'd be an easy vector for contamination of > email contents into a filesystem request. Can we reasonably place such a > restriction, though? I'd hate to force implementations to special-case > their string expansions. Other extensions already have such limitations (e.g. notify) and the variables extension explicitly states that future commands may choose not to allow variables in some of their arguments (the so-called constant string). However, I agree that we should not limit the flexibility of the command more than necessary. Perhaps an explicit mention in the Security Considerations section would suffice to cover our bases. On the other hand, one may argue how useful it is to use variables in the include argument in the first place: there are a (known) limited amount of scripts in the Sieve storage and making choices can be done using if commands surrounding multiple alternative include commands. People using variables could even make their scripts highly unreliable, since include commands kill Sieve execution when the indicated script does not exist. Perhaps in combination with an ':optional' modifier, variables could be used to change the behavior of a script without actually modifying it. For instance, when a script is added to the Sieve store with a name that matches the sender address, it is included automatically when a message from that person comes in. That sounds a bit freaky though :) >> - The scope of the :once modifier could be a bit confusing. I am >> assuming it holds for the whole Sieve execution and not only for the >> identical include commands within the current script. > > Correct. Could you suggest how I might clarify that it's the whole > execution? I feel like I'm missing the right word for being inside one file > vs. being inside one delivery/execution instance. I am still not sure what to do here. I guess it is also important to mention that the scope of the :once modifier does not extend into the other scripts of a multiscript sequence (and any scripts included by those).. or does it? For this distinction it matters whether you call it the 'whole Sieve execution', as this would include truly everything. Regards, -- Stephan Bosch stephan@rename-it.nl From owner-ietf-mta-filters@mail.imc.org Tue Apr 14 06:48:15 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FC13A6D98 for ; Tue, 14 Apr 2009 06:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAjQn-qh1V0P for ; Tue, 14 Apr 2009 06:48:14 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3EBE13A6C19 for ; Tue, 14 Apr 2009 06:48:13 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EDaZRq022836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 06:36:35 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EDaZjd022835; Tue, 14 Apr 2009 06:36:35 -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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EDaLEo022816 for ; Tue, 14 Apr 2009 06:36:33 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id E7F6A2E2B5; Tue, 14 Apr 2009 15:36:12 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1239716172-2912-2909/6/1 (4 recipients); Tue, 14 Apr 2009 15:36:12 +0200 Message-Id: Date: Tue, 14 Apr 2009 15:36:20 +0200 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt Cc: Aaron Stone , Stephan Bosch Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Aaron Stone answers Stephan Bosch: >> - Where the ManageSieve protocol specifies what characters are >> allowed for a script name, the include extension for the Sieve >> language does not. Would it be useful to adopt the same >> limitations? Especially things like '/' can cause problems. > > Good suggestion. I think this makes sense to give a consistent opinion > on what script names should look like, but on the other hand, perhaps > it's possible that someone isn't using ManageSieve but IS using > include and might need to get at weird names? Do we care in that > case? If so, then they probably will use managesieve at some point anyway. >> - The global command is required to follow 'require' or another >> global command. I am worried what happens when other extensions >> have commands with similar requirements. Shouldn't we account for >> this eventuality? > > I don't like this restriction anyways. Any objection to lifting it? (I don't feel qualified to have an opinion on this issue.) >> - The scope of the :once modifier could be a bit confusing. I am >> assuming it holds for the whole Sieve execution and not only for >> the identical include commands within the current script. > > Correct. Could you suggest how I might clarify that it's the whole > execution? I feel like I'm missing the right word for being inside > one file vs. being inside one delivery/execution instance. I think that's enough of an issue that it's worth a whole sentence or two. I like precise words. But sometimes you can be as precise as you want, and someone will read the text after being up half the night with the crying baby and won't get it. Or zero words perhaps. Why is :once justified? is "mandatory :once" or ":once not supported" good enough? Arnt From owner-ietf-mta-filters@mail.imc.org Wed Apr 15 15:58:54 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BC83A698C for ; Wed, 15 Apr 2009 15:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdJYxW9DmNyj for ; Wed, 15 Apr 2009 15:58:53 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 270693A683A for ; Wed, 15 Apr 2009 15:58:52 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FMnEnZ067783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 15:49:14 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FMnEa6067782; Wed, 15 Apr 2009 15:49:14 -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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FMn2Is067770 for ; Wed, 15 Apr 2009 15:49:13 -0700 (MST) (envelope-from lisa.dusseault@gmail.com) Received: by qw-out-1920.google.com with SMTP id 5so118135qwc.28 for ; Wed, 15 Apr 2009 15:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T63Oyr11W7QSB/gGOXegZquvcQX+KPYmUyVo3X4c/H8=; b=xfz/tZB+bdj1wSM2uMk3la2w2XlsldkFua2imReCN/249pEDv3WKqMI1z+QYYn1Sar UraLPCA2qJwZdLDXdpspsY2A44MYpOZRKRV8F+zGSVXqgiQEI3UL4qiv8tLkfkRse7Lx sZB4UI/nPfXNPGEFMV6oZC7mAhXsq/1Is9Yfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nRvFnq2CxqsrJSQ+48lmaGhOreO1AJSx80fScifP+KO3/0DSqMSU72315Y8yPS3+07 zLxWdTRVLMV2FvUAtSoQHa4E2caz7ij3G4biO2vD7IHR8kMx3gnLgW+xSw5uImynIVth jwGbZfIfAkVaz6wzf7cb3Ax7mlL6VjiJ6Xpos= MIME-Version: 1.0 Received: by 10.220.46.146 with SMTP id j18mr169213vcf.45.1239835742084; Wed, 15 Apr 2009 15:49:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Apr 2009 15:49:02 -0700 Message-ID: Subject: Re: [sieve-in-xml] Example Scripts For Integration Testing From: Lisa Dusseault To: Robert Burrell Donkin Cc: MTA filtering mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some WGs have actually done this as RFCs: e.g. http://www.ietf.org/rfc/rfc3665.txt In some cases, it's no problem doing this (even if out-of-scope) as an ad-hoc activity on the WG mailing list, though that's up to the chairs and they could always suggest the activity move elsewhere. I suppose if there's effectively a code-base rather than an Internet-Draft, it might be nicer to use a open-source collaboration site with SVN as well as forums instead of this mailing list anyway -- so it depends also on participation and activity level as well as how the corpus is structured. Lisa On Thu, Apr 9, 2009 at 1:16 AM, Robert Burrell Donkin wrote: > > i'm much happier with the current sieve-in-xml draft. we hope to ship > JSieve soon with experimental preview partial support with the hope > that usage by developers may help to understand whether any issues > have been missed, with a complete implementation would be targetted > for the next release. > > however, to confidently ship a library claiming full support, a > reasonably large and fully debugged corpus of integration tests is > needed: basically, example sieve scripts together with corresponding > sieve-in-xml documents. IMO this is the sort of data which is usually > best developed and debugged collectively. > > from the sieve working group charter: > >
> (5) Produce one or more informational RFCs containing a set of test > scripts and test email messages that are to be filtered by the scripts, > and the expected results of that filtering. This will serve as the basis > of a interoperability test suite to help determine the suitability of > moving the base specification and selected extensions to Draft status. >
> > as i read this, a collection of example sieve scripts and sieve-in-xml > documents is out of scope for this group (hopefully people will jump > in if my reading is incorrect) > > so, i was wondering whether there is any interest from members of the > group in collaborating offshore (http://code.google.com, say) on > creating and debugging such a corpus as an open source project under a > very permissive license (MIT, say), or whether there are any other > good ways that such a corpus could be created and made freely > available > > - robert > > From owner-ietf-mta-filters@mail.imc.org Mon Apr 27 04:28:54 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469793A6A99 for ; Mon, 27 Apr 2009 04:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meip+-e6TPJa for ; Mon, 27 Apr 2009 04:28:53 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 4CFFA3A6B29 for ; Mon, 27 Apr 2009 04:28:53 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBCxtH018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 04:12:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RBCxCc018729; Mon, 27 Apr 2009 04:12: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 mout2.freenet.de (mout2.freenet.de [195.4.92.92]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBCkZP018667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Apr 2009 04:12:58 -0700 (MST) (envelope-from michael.haardt@freenet.ag) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout2.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #88) id 1LyOlR-0005Ex-2o; Mon, 27 Apr 2009 13:12:45 +0200 Received: from nostromo.freenet-ag.de ([2001:748:100:10::2]:53847) by 8.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #79) id 1LyOlR-0002EQ-1g; Mon, 27 Apr 2009 13:12:45 +0200 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #91) id 1LyOlQ-00017A-74; Mon, 27 Apr 2009 13:12:44 +0200 Date: Mon, 27 Apr 2009 13:12:44 +0200 To: ietf-mta-filters@imc.org, arnt@oryx.com Subject: Re: notify and valid_notify_method References: In-Reply-To: User-Agent: Heirloom mailx 12.1 6/15/06 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Michael Haardt Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Supposed to return true if all exist and are valid and supported and > generally polished, and false if at least one has some imperfection. > > But what if the list is empty? Sounds like a degenerate true, agreed? A string list can't be empty. Michael From owner-ietf-mta-filters@mail.imc.org Mon Apr 27 04:51:13 2009 Return-Path: X-Original-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Delivered-To: ietfarch-sieve-archive-Aet6aiqu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E57E63A6D97 for ; Mon, 27 Apr 2009 04:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knqxQc25BSWJ for ; Mon, 27 Apr 2009 04:51:13 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DF1223A6CEE for ; Mon, 27 Apr 2009 04:51:10 -0700 (PDT) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBdXIJ021316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 04:39:33 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RBdXRj021315; Mon, 27 Apr 2009 04:39:33 -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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBdMfN021285 for ; Mon, 27 Apr 2009 04:39:33 -0700 (MST) (envelope-from arnt@oryx.com) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 036382E2A9; Mon, 27 Apr 2009 13:39:04 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1240832343-57764-57763/6/64 for ietf-mta-filters@imc.org; Mon, 27 Apr 2009 13:39:03 +0200 Message-Id: Date: Mon, 27 Apr 2009 13:39:42 +0200 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: notify and valid_notify_method References: In-Reply-To: Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Michael Haardt writes: >> Supposed to return true if all exist and are valid and supported and >> generally polished, and false if at least one has some >> imperfection. >> >> But what if the list is empty? Sounds like a degenerate true, agreed? > > A string list can't be empty. OK. I thought variables changed that, though... wasn't there a draft to read varables from sources outside sieve? Called something lie server or metadata or something? Can't find it now. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBdXIJ021316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 04:39:33 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RBdXRj021315; Mon, 27 Apr 2009 04:39:33 -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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBdMfN021285 for ; Mon, 27 Apr 2009 04:39:33 -0700 (MST) (envelope-from arnt@oryx.com) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 036382E2A9; Mon, 27 Apr 2009 13:39:04 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1240832343-57764-57763/6/64 for ietf-mta-filters@imc.org; Mon, 27 Apr 2009 13:39:03 +0200 Message-Id: Date: Mon, 27 Apr 2009 13:39:42 +0200 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: notify and valid_notify_method References: In-Reply-To: Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Michael Haardt writes: >> Supposed to return true if all exist and are valid and supported and >> generally polished, and false if at least one has some >> imperfection. >> >> But what if the list is empty? Sounds like a degenerate true, agreed? > > A string list can't be empty. OK. I thought variables changed that, though... wasn't there a draft to read varables from sources outside sieve? Called something lie server or metadata or something? Can't find it now. Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBCxtH018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 04:12:59 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3RBCxCc018729; Mon, 27 Apr 2009 04:12: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 mout2.freenet.de (mout2.freenet.de [195.4.92.92]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3RBCkZP018667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Apr 2009 04:12:58 -0700 (MST) (envelope-from michael.haardt@freenet.ag) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout2.freenet.de with esmtpa (ID exim) (port 25) (Exim 4.69 #88) id 1LyOlR-0005Ex-2o; Mon, 27 Apr 2009 13:12:45 +0200 Received: from nostromo.freenet-ag.de ([2001:748:100:10::2]:53847) by 8.mx.freenet.de with esmtps (TLSv1:AES256-SHA:256) (port 25) (Exim 4.69 #79) id 1LyOlR-0002EQ-1g; Mon, 27 Apr 2009 13:12:45 +0200 Received: from michael by nostromo.freenet-ag.de with local (ID michael) (Exim 4.69 #91) id 1LyOlQ-00017A-74; Mon, 27 Apr 2009 13:12:44 +0200 Date: Mon, 27 Apr 2009 13:12:44 +0200 To: ietf-mta-filters@imc.org, arnt@oryx.com Subject: Re: notify and valid_notify_method References: In-Reply-To: User-Agent: Heirloom mailx 12.1 6/15/06 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Michael Haardt Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Supposed to return true if all exist and are valid and supported and > generally polished, and false if at least one has some imperfection. > > But what if the list is empty? Sounds like a degenerate true, agreed? A string list can't be empty. Michael Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FMnEnZ067783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Apr 2009 15:49:14 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3FMnEa6067782; Wed, 15 Apr 2009 15:49:14 -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 qw-out-1920.google.com (qw-out-1920.google.com [74.125.92.144]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3FMn2Is067770 for ; Wed, 15 Apr 2009 15:49:13 -0700 (MST) (envelope-from lisa.dusseault@gmail.com) Received: by qw-out-1920.google.com with SMTP id 5so118135qwc.28 for ; Wed, 15 Apr 2009 15:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=T63Oyr11W7QSB/gGOXegZquvcQX+KPYmUyVo3X4c/H8=; b=xfz/tZB+bdj1wSM2uMk3la2w2XlsldkFua2imReCN/249pEDv3WKqMI1z+QYYn1Sar UraLPCA2qJwZdLDXdpspsY2A44MYpOZRKRV8F+zGSVXqgiQEI3UL4qiv8tLkfkRse7Lx sZB4UI/nPfXNPGEFMV6oZC7mAhXsq/1Is9Yfo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nRvFnq2CxqsrJSQ+48lmaGhOreO1AJSx80fScifP+KO3/0DSqMSU72315Y8yPS3+07 zLxWdTRVLMV2FvUAtSoQHa4E2caz7ij3G4biO2vD7IHR8kMx3gnLgW+xSw5uImynIVth jwGbZfIfAkVaz6wzf7cb3Ax7mlL6VjiJ6Xpos= MIME-Version: 1.0 Received: by 10.220.46.146 with SMTP id j18mr169213vcf.45.1239835742084; Wed, 15 Apr 2009 15:49:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Apr 2009 15:49:02 -0700 Message-ID: Subject: Re: [sieve-in-xml] Example Scripts For Integration Testing From: Lisa Dusseault To: Robert Burrell Donkin Cc: MTA filtering mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some WGs have actually done this as RFCs: e.g. http://www.ietf.org/rfc/rfc3665.txt In some cases, it's no problem doing this (even if out-of-scope) as an ad-hoc activity on the WG mailing list, though that's up to the chairs and they could always suggest the activity move elsewhere. I suppose if there's effectively a code-base rather than an Internet-Draft, it might be nicer to use a open-source collaboration site with SVN as well as forums instead of this mailing list anyway -- so it depends also on participation and activity level as well as how the corpus is structured. Lisa On Thu, Apr 9, 2009 at 1:16 AM, Robert Burrell Donkin wrote: > > i'm much happier with the current sieve-in-xml draft. we hope to ship > JSieve soon with experimental preview partial support with the hope > that usage by developers may help to understand whether any issues > have been missed, with a complete implementation would be targetted > for the next release. > > however, to confidently ship a library claiming full support, a > reasonably large and fully debugged corpus of integration tests is > needed: basically, example sieve scripts together with corresponding > sieve-in-xml documents. IMO this is the sort of data which is usually > best developed and debugged collectively. > > from the sieve working group charter: > >
> (5) Produce one or more informational RFCs containing a set of test > scripts and test email messages that are to be filtered by the scripts, > and the expected results of that filtering. This will serve as the basis > of a interoperability test suite to help determine the suitability of > moving the base specification and selected extensions to Draft status. >
> > as i read this, a collection of example sieve scripts and sieve-in-xml > documents is out of scope for this group (hopefully people will jump > in if my reading is incorrect) > > so, i was wondering whether there is any interest from members of the > group in collaborating offshore (http://code.google.com, say) on > creating and debugging such a corpus as an open source project under a > very permissive license (MIT, say), or whether there are any other > good ways that such a corpus could be created and made freely > available > > - robert > > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EDaZRq022836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 06:36:35 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3EDaZjd022835; Tue, 14 Apr 2009 06:36:35 -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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3EDaLEo022816 for ; Tue, 14 Apr 2009 06:36:33 -0700 (MST) (envelope-from arnt@gulbrandsen.priv.no) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id E7F6A2E2B5; Tue, 14 Apr 2009 15:36:12 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1239716172-2912-2909/6/1 (4 recipients); Tue, 14 Apr 2009 15:36:12 +0200 Message-Id: Date: Tue, 14 Apr 2009 15:36:20 +0200 From: Arnt Gulbrandsen To: ietf-mta-filters@imc.org Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt Cc: Aaron Stone , Stephan Bosch Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Aaron Stone answers Stephan Bosch: >> - Where the ManageSieve protocol specifies what characters are >> allowed for a script name, the include extension for the Sieve >> language does not. Would it be useful to adopt the same >> limitations? Especially things like '/' can cause problems. > > Good suggestion. I think this makes sense to give a consistent opinion > on what script names should look like, but on the other hand, perhaps > it's possible that someone isn't using ManageSieve but IS using > include and might need to get at weird names? Do we care in that > case? If so, then they probably will use managesieve at some point anyway. >> - The global command is required to follow 'require' or another >> global command. I am worried what happens when other extensions >> have commands with similar requirements. Shouldn't we account for >> this eventuality? > > I don't like this restriction anyways. Any objection to lifting it? (I don't feel qualified to have an opinion on this issue.) >> - The scope of the :once modifier could be a bit confusing. I am >> assuming it holds for the whole Sieve execution and not only for >> the identical include commands within the current script. > > Correct. Could you suggest how I might clarify that it's the whole > execution? I feel like I'm missing the right word for being inside > one file vs. being inside one delivery/execution instance. I think that's enough of an issue that it's worth a whole sentence or two. I like precise words. But sometimes you can be as precise as you want, and someone will read the text after being up half the night with the crying baby and won't get it. Or zero words perhaps. Why is :once justified? is "mandatory :once" or ":once not supported" good enough? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B82rrg066106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 01:02:53 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B82r4M066105; Sat, 11 Apr 2009 01:02:53 -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 cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B82dkc066094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 11 Apr 2009 01:02:52 -0700 (MST) (envelope-from stephan@rename-it.nl) Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LsYAP-0000dR-Py; Sat, 11 Apr 2009 10:02:21 +0200 Message-ID: <49E04E83.20001@rename-it.nl> Date: Sat, 11 Apr 2009 10:02:11 +0200 From: Stephan Bosch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Aaron Stone CC: SIEVE Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt References: <49DFD8CE.6020306@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-VirusScan: Found to be clean X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.581, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.42, BAYES_00 -2.60) X-RenameIT-MailScanner-From: stephan@rename-it.nl X-Spam-Status: No Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Aaron, Aaron Stone wrote: > Thanks for your comments. I'd been preparing to send an email to the list > announcing the changes and requesting feedback. You've touched on all the > good points. So let's run with this thread! > > On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch > wrote: >> First of all, I am very glad that the work on the specification is being >> continued now. This week I quickly updated my implementation to match >> the new specification. Merging import and export into a single global >> command is a good choice. The use of a global variable namespace is also >> a good idea (but I did not implement that yet). > > I actually wonder if we should drop the global keyword and rely on > namespaces entirely. The global namespace has one disadvantage: it makes all global variable names longer ('global.*'). Especially when a variable is used often in a script, this may become tedious. Using the global command, it is possible to pull global variables into the script namespace, which is convenient in such situations. I guess it would be best to support both methods of accessing global variables (and to even allow mixing these freely). >> - Where the ManageSieve protocol specifies what characters are allowed >> for a script name, the include extension for the Sieve language does >> not. Would it be useful to adopt the same limitations? Especially things >> like '/' can cause problems. > > Good suggestion. I think this makes sense to give a consistent opinion on > what script names should look like, but on the other hand, perhaps it's > possible that someone isn't using ManageSieve but IS using include and > might need to get at weird names? Do we care in that case? You can also make it a recommendation. As long as implementers know that there is some consensus about what a script name is supposed to be and that script names should not be mapped directly to files for security reasons. >> - The global command is required to follow 'require' or another global >> command. I am worried what happens when other extensions have commands >> with similar requirements. Shouldn't we account for this eventuality? > I don't like this restriction anyways. Any objection to lifting it? Hmm, interesting suggestion. The main implication of this is that the inclusion of global variables into the script namespace can become conditional, i.e. when it is placed into an if statement. I don't know whether this is desirable. You could also state that the global command needs to be placed after require commands or any command that also needs to be placed directly below the require commands (choose better wording though). This implies no ordering between the commands that follow the require section, avoiding problems with future commands with similar needs. >> - Are there any special security implications for using variables in the >> value argument in the include command, i.e. to include a script >> specified by a variable? Is that even (intended to be) allowed? > > Oh, that's a good question. That'd be an easy vector for contamination of > email contents into a filesystem request. Can we reasonably place such a > restriction, though? I'd hate to force implementations to special-case > their string expansions. Other extensions already have such limitations (e.g. notify) and the variables extension explicitly states that future commands may choose not to allow variables in some of their arguments (the so-called constant string). However, I agree that we should not limit the flexibility of the command more than necessary. Perhaps an explicit mention in the Security Considerations section would suffice to cover our bases. On the other hand, one may argue how useful it is to use variables in the include argument in the first place: there are a (known) limited amount of scripts in the Sieve storage and making choices can be done using if commands surrounding multiple alternative include commands. People using variables could even make their scripts highly unreliable, since include commands kill Sieve execution when the indicated script does not exist. Perhaps in combination with an ':optional' modifier, variables could be used to change the behavior of a script without actually modifying it. For instance, when a script is added to the Sieve store with a name that matches the sender address, it is included automatically when a message from that person comes in. That sounds a bit freaky though :) >> - The scope of the :once modifier could be a bit confusing. I am >> assuming it holds for the whole Sieve execution and not only for the >> identical include commands within the current script. > > Correct. Could you suggest how I might clarify that it's the whole > execution? I feel like I'm missing the right word for being inside one file > vs. being inside one delivery/execution instance. I am still not sure what to do here. I guess it is also important to mention that the scope of the :once modifier does not extend into the other scripts of a multiscript sequence (and any scripts included by those).. or does it? For this distinction it matters whether you call it the 'whole Sieve execution', as this would include truly everything. Regards, -- Stephan Bosch stephan@rename-it.nl Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3B0aBGd047273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 17:36:11 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3B0aBHX047272; Fri, 10 Apr 2009 17:36:11 -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.14.2/8.14.2) with ESMTP id n3B0a0W5047249 for ; Fri, 10 Apr 2009 17:36:10 -0700 (MST) (envelope-from aaron@serendipity.cx) Received: from serendipity.cx (unknown [10.10.10.34]) by mail.serendipity.cx (Postfix) with ESMTP id 1203F2936; Fri, 10 Apr 2009 17:37:39 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 10 Apr 2009 17:37:39 -0700 From: Aaron Stone To: Stephan Bosch Cc: SIEVE Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt In-Reply-To: <49DFD8CE.6020306@rename-it.nl> References: <49DFD8CE.6020306@rename-it.nl> Message-ID: X-Sender: aaron@serendipity.cx User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks for your comments. I'd been preparing to send an email to the list announcing the changes and requesting feedback. You've touched on all the good points. So let's run with this thread! On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch wrote: > Hi, > > First of all, I am very glad that the work on the specification is being > continued now. This week I quickly updated my implementation to match > the new specification. Merging import and export into a single global > command is a good choice. The use of a global variable namespace is also > a good idea (but I did not implement that yet). I actually wonder if we should drop the global keyword and rely on namespaces entirely. > During implementation I collected some remarks and questions: > > - Where the ManageSieve protocol specifies what characters are allowed > for a script name, the include extension for the Sieve language does > not. Would it be useful to adopt the same limitations? Especially things > like '/' can cause problems. Good suggestion. I think this makes sense to give a consistent opinion on what script names should look like, but on the other hand, perhaps it's possible that someone isn't using ManageSieve but IS using include and might need to get at weird names? Do we care in that case? > - For the global command I would expect text stating that the variables > extension is required when it is used. Will add. > - The global command is required to follow 'require' or another global > command. I am worried what happens when other extensions have commands > with similar requirements. Shouldn't we account for this eventuality? I don't like this restriction anyways. Any objection to lifting it? > - Are there any special security implications for using variables in the > value argument in the include command, i.e. to include a script > specified by a variable? Is that even (intended to be) allowed? Oh, that's a good question. That'd be an easy vector for contamination of email contents into a filesystem request. Can we reasonably place such a restriction, though? I'd hate to force implementations to special-case their string expansions. > - The scope of the :once modifier could be a bit confusing. I am > assuming it holds for the whole Sieve execution and not only for the > identical include commands within the current script. Correct. Could you suggest how I might clarify that it's the whole execution? I feel like I'm missing the right word for being inside one file vs. being inside one delivery/execution instance. > - Take a good look at the examples: they have small typos and syntax > problems: > * page 6; spam_tests: reject command has mandatory message argument > * page 7; spam_tests: reject command has mandatory message argument > * page 8; active script: test-mailbox is not a valid variable name > * page 8; active script: missing require for relational extension > * page 9; active scropt: :count match type needs an argument, e.g. > "eq" > * page 9; active script: "spam-${test}; <- missing " Will correct these. > Please let me know what you think. Thanks! Aaron Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ANeL7u044095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 16:40:21 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n3ANeLN8044094; Fri, 10 Apr 2009 16:40: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 cola.rename-it.nl (cola.rename-it.nl [217.119.231.192]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n3ANe89f044065 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 10 Apr 2009 16:40:20 -0700 (MST) (envelope-from stephan@rename-it.nl) Received: from klara.student.utwente.nl ([130.89.162.218] helo=[10.168.3.2]) by cola.rename-it.nl with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LsQKC-00014g-Qz for ietf-mta-filters@imc.org; Sat, 11 Apr 2009 01:39:56 +0200 Message-ID: <49DFD8CE.6020306@rename-it.nl> Date: Sat, 11 Apr 2009 01:39:58 +0200 From: Stephan Bosch User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIEVE Subject: Questions and remarks on draft-ietf-sieve-include-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-VirusScan: Found to be clean X-RenameIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.575, required 5, autolearn=not spam, ALL_TRUSTED -0.40, AWL 1.42, BAYES_00 -2.60) X-RenameIT-MailScanner-From: stephan@rename-it.nl X-Spam-Status: No Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, First of all, I am very glad that the work on the specification is being continued now. This week I quickly updated my implementation to match the new specification. Merging import and export into a single global command is a good choice. The use of a global variable namespace is also a good idea (but I did not implement that yet). During implementation I collected some remarks and questions: - Where the ManageSieve protocol specifies what characters are allowed for a script name, the include extension for the Sieve language does not. Would it be useful to adopt the same limitations? Especially things like '/' can cause problems. - For the global command I would expect text stating that the variables extension is required when it is used. - The global command is required to follow 'require' or another global command. I am worried what happens when other extensions have commands with similar requirements. Shouldn't we account for this eventuality? - Are there any special security implications for using variables in the value argument in the include command, i.e. to include a script specified by a variable? Is that even (intended to be) allowed? - The scope of the :once modifier could be a bit confusing. I am assuming it holds for the whole Sieve execution and not only for the identical include commands within the current script. - Take a good look at the examples: they have small typos and syntax problems: * page 6; spam_tests: reject command has mandatory message argument * page 7; spam_tests: reject command has mandatory message argument * page 8; active script: test-mailbox is not a valid variable name * page 8; active script: missing require for relational extension * page 9; active scropt: :count match type needs an argument, e.g. "eq" * page 9; active script: "spam-${test}; <- missing " Please let me know what you think. Regards, -- Stephan Bosch stephan@rename-it.nl Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n398GkHF090988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Apr 2009 01:16:47 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n398Gkoi090987; Thu, 9 Apr 2009 01:16:46 -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-bw0-f176.google.com (mail-bw0-f176.google.com [209.85.218.176]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n398GiGf090978 for ; Thu, 9 Apr 2009 01:16:45 -0700 (MST) (envelope-from robertburrelldonkin@gmail.com) Received: by bwz24 with SMTP id 24so471154bwz.10 for ; Thu, 09 Apr 2009 01:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=LjVnrpmZCwg3umIH2ksk128nSDMQdCHunlAgklVqtu0=; b=iASNyzahI+R8/2cTba/xy8QTdwynGX9Opphd47mu3fWtZkwoHZm68fRMRHZFxm7a1M F5xkSbCAv1SiK3oaI2tZWoi8iWXiLxNoVSWD2E/xs81BZvC/pHY0Q8BPKeRPn3dvI7Y/ H7rNlfE7OWUXggsrYTeo6ZgqZvAuGJwHdv+GQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=nA7FXPJb+F/t7QSvTIGmjipBhyFF6/027qU2pMSWiEMhLGvxKuh7Cnz3KjFADmza/E 9LuDL1jl2T7qsfgeEbddV253zPFOVgTuxDxZVyQii7IRwh+3i5tyRbXveKnNngqzlWo7 8as71J5ErVec+h6wbXzz3dww5HWVsEOAFFWMM= MIME-Version: 1.0 Received: by 10.204.113.203 with SMTP id b11mr1951159bkq.109.1239265003832; Thu, 09 Apr 2009 01:16:43 -0700 (PDT) Date: Thu, 9 Apr 2009 09:16:43 +0100 Message-ID: Subject: [sieve-in-xml] Example Scripts For Integration Testing From: Robert Burrell Donkin To: MTA filtering mailing list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: i'm much happier with the current sieve-in-xml draft. we hope to ship JSieve soon with experimental preview partial support with the hope that usage by developers may help to understand whether any issues have been missed, with a complete implementation would be targetted for the next release. however, to confidently ship a library claiming full support, a reasonably large and fully debugged corpus of integration tests is needed: basically, example sieve scripts together with corresponding sieve-in-xml documents. IMO this is the sort of data which is usually best developed and debugged collectively. from the sieve working group charter:
(5) Produce one or more informational RFCs containing a set of test scripts and test email messages that are to be filtered by the scripts, and the expected results of that filtering. This will serve as the basis of a interoperability test suite to help determine the suitability of moving the base specification and selected extensions to Draft status.
as i read this, a collection of example sieve scripts and sieve-in-xml documents is out of scope for this group (hopefully people will jump in if my reading is incorrect) so, i was wondering whether there is any interest from members of the group in collaborating offshore (http://code.google.com, say) on creating and debugging such a corpus as an open source project under a very permissive license (MIT, say), or whether there are any other good ways that such a corpus could be created and made freely available - robert Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37DYg99096266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2009 06:34:42 -0700 (MST) (envelope-from owner-ietf-mta-filters@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n37DYgGP096265; Tue, 7 Apr 2009 06:34:42 -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 kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n37DYU66096243 for ; Tue, 7 Apr 2009 06:34:41 -0700 (MST) (envelope-from arnt@oryx.com) Received: from kalyani.oryx.com (localhost [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id 190D32E25F; Tue, 7 Apr 2009 15:34:27 +0200 (CEST) Received: from arnt@oryx.com (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1239111266-53296-53284/6/15 (2 recipients); Tue, 7 Apr 2009 15:34:26 +0200 Message-Id: Date: Tue, 7 Apr 2009 15:34:45 +0200 From: Arnt Gulbrandsen To: MTA filtering mailing list Subject: notify and valid_notify_method Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-mta-filters@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Supposed to return true if all exist and are valid and supported and generally polished, and false if at least one has some imperfection. But what if the list is empty? Sounds like a degenerate true, agreed? Arnt