From barryleiba.mailing.lists@gmail.com Sun Oct 2 07:17:54 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24721F84DC for ; Sun, 2 Oct 2011 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.967 X-Spam-Level: X-Spam-Status: No, score=-102.967 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q6nkFpp+mss for ; Sun, 2 Oct 2011 07:17:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0731C21F84DA for ; Sun, 2 Oct 2011 07:17:52 -0700 (PDT) Received: by ywm3 with SMTP id 3so164616ywm.31 for ; Sun, 02 Oct 2011 07:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ddK2cp1XuUL2IK7L9l4zD78f/4BLyrGe4H5bg72arao=; b=Prlrhe5xIl2Zm2qGb1el6vkXwlmArsj5FrezAeoQ1TBlBVw2J0btJWjktWa18O+AUB tzBtJ1GuIxxRrWmEYu0FiJ8DO3Wa50mkwiJKEaCVVuWaPq7LRezYPXqTEFtGsZdblnKI T4kT0BxoUpaqyiXx0ZMku4yVT7kG9rBRJPIAM= MIME-Version: 1.0 Received: by 10.236.191.71 with SMTP id f47mr81331586yhn.125.1317565251662; Sun, 02 Oct 2011 07:20:51 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.83.8 with HTTP; Sun, 2 Oct 2011 07:20:51 -0700 (PDT) In-Reply-To: References: Date: Sun, 2 Oct 2011 10:20:51 -0400 X-Google-Sender-Auth: _ucrl4Wn9IKdMmtQ5gE6NMhzPik Message-ID: From: Barry Leiba To: Aaron Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: sieve@ietf.org Subject: Re: [sieve] Clarifying "implementations MUST NOT allow variable expansion in the script name argument" [WAS Re: I-D Action: draft-ietf-sieve-include-12.txt] X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 14:17:54 -0000 > I posted -13. Please check if your suggested changes are as you expected. I've looked at the diffs, and I'm satisfied that the comments have been addressed. I'll give it a couple more days to see if anyone has anything to say about it, and then I plan to send this to Pete on Tuesday. Barry, document shepherd From internet-drafts@ietf.org Tue Oct 4 04:35:17 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27B221F8CA3; Tue, 4 Oct 2011 04:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sqoiSh4ZNeW; Tue, 4 Oct 2011 04:35:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4799321F8B8B; Tue, 4 Oct 2011 04:35:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111004113517.6414.97652.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2011 04:35:17 -0700 Cc: sieve@ietf.org Subject: [sieve] I-D Action: draft-ietf-sieve-notify-sip-message-06.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 11:35:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sieve Mail Filtering Language Working= Group of the IETF. Title : Sieve Notification Mechanism: SIP MESSAGE Author(s) : Alexey Melnikov Qian Sun Barry Leiba Kepeng Li Filename : draft-ietf-sieve-notify-sip-message-06.txt Pages : 11 Date : 2011-10-04 This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-sip-message-06.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sieve-notify-sip-message-06.t= xt From internet-drafts@ietf.org Fri Oct 7 16:52:03 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7872E21F86C1; Fri, 7 Oct 2011 16:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArfwHg+MA3+W; Fri, 7 Oct 2011 16:52:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BC621F85A4; Fri, 7 Oct 2011 16:52:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111007235203.16761.75768.idtracker@ietfa.amsl.com> Date: Fri, 07 Oct 2011 16:52:03 -0700 Cc: sieve@ietf.org Subject: [sieve] I-D Action: draft-ietf-sieve-notify-sip-message-07.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 23:52:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sieve Mail Filtering Language Working= Group of the IETF. Title : Sieve Notification Mechanism: SIP MESSAGE Author(s) : Alexey Melnikov Qian Sun Barry Leiba Kepeng Li Filename : draft-ietf-sieve-notify-sip-message-07.txt Pages : 11 Date : 2011-10-07 This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-sip-message-07.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sieve-notify-sip-message-07.t= xt From internet-drafts@ietf.org Tue Oct 11 12:14:42 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 470AE1F0C38; Tue, 11 Oct 2011 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnfKHsPUVNA4; Tue, 11 Oct 2011 12:14:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAFE1F0C35; Tue, 11 Oct 2011 12:14:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111011191429.5976.73094.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 12:14:29 -0700 Cc: sieve@ietf.org Subject: [sieve] I-D Action: draft-ietf-sieve-notify-sip-message-08.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 19:14:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sieve Mail Filtering Language Working= Group of the IETF. Title : Sieve Notification Mechanism: SIP MESSAGE Author(s) : Alexey Melnikov Qian Sun Barry Leiba Kepeng Li Filename : draft-ietf-sieve-notify-sip-message-08.txt Pages : 11 Date : 2011-10-11 This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-notify-sip-message-08.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sieve-notify-sip-message-08.t= xt From barryleiba.mailing.lists@gmail.com Fri Oct 14 08:21:18 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B609321F84C2 for ; Fri, 14 Oct 2011 08:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+u609gs0z1I for ; Fri, 14 Oct 2011 08:21:18 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 318BE21F8562 for ; Fri, 14 Oct 2011 08:21:18 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1298584vcb.31 for ; Fri, 14 Oct 2011 08:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AdTxGkm73vPHMqCm3LFlWSyr9U/TBo+ds+RCcegnucc=; b=kNKeZenHf306rCL7tdyLOpy4xNLydb9HkfPwmAk3VGhE1lTgA21zO1z5gVbisw8gk8 oxt3lZmEbY4BA/GVlsarjNSVRf0730ebJ15S0pVOwZBG0cmcDcxtXPZgpR9R+pF6+wtx gii6LNBhBwgPeCNlVsMkGtaOu3mDeIvgDv5WI= MIME-Version: 1.0 Received: by 10.220.118.4 with SMTP id t4mr681165vcq.106.1318605677535; Fri, 14 Oct 2011 08:21:17 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.220.201.77 with HTTP; Fri, 14 Oct 2011 08:21:17 -0700 (PDT) In-Reply-To: <20110924182110.30745.28586.idtracker@ietfa.amsl.com> References: <20110924182110.30745.28586.idtracker@ietfa.amsl.com> Date: Fri, 14 Oct 2011 11:21:17 -0400 X-Google-Sender-Auth: _UlmnbnSYjhodAtWWUzGyP2gCeo Message-ID: From: Barry Leiba To: sieve@ietf.org, sieve-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sieve-ads@tools.ietf.org Subject: Re: [sieve] I-D Action: draft-ietf-sieve-convert-04.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 15:21:18 -0000 Trying again: On Sat, Sep 24, 2011 at 2:30 PM, Barry Leiba wrot= e: > > -04 has been posted. =A0Will the chairs please do the PROTO writeup and > send it to the ADs? Barry From stephan@rename-it.nl Mon Oct 17 12:24:00 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508E321F8CCF for ; Mon, 17 Oct 2011 12:24:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP3JIygfJAT6 for ; Mon, 17 Oct 2011 12:23:59 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id B7CF121F8C93 for ; Mon, 17 Oct 2011 12:23:58 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:54648 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFsmv-00073q-0B; Mon, 17 Oct 2011 21:23:54 +0200 Message-ID: <4E9C809D.90808@rename-it.nl> Date: Mon, 17 Oct 2011 21:23:09 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Aaron Stone References: <20110923192026.30531.70942.idtracker@ietfa.amsl.com> <4E7DDF5A.4060505@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Cc: Sieve mailing list Subject: Re: [sieve] I-D Action: draft-ietf-sieve-include-11.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 19:24:00 -0000 On 9/27/2011 10:02 PM, Aaron Stone wrote: > On Sat, Sep 24, 2011 at 6:47 AM, Stephan Bosch wrote: >> So, from this I understand that the foreverypart context is passed down to >> any script included while in this context. This means that the behavior of >> the :mime-augmented tests in the included scripts is influenced accordingly. > I don't see why the context would be passed along, but I'll note > explicitly that it is not: > > OLD: > 255 The "include" command MAY appear anywhere in a script where a > 256 control structure is legal, and MAY be used within another control > 257 structure, e.g., within an "if" or "foreverypart" block > (MIME). > > NEW: > 255 The "include" command MAY appear anywhere in a script where a > 256 control structure is legal, and MAY be used within another control > 257 structure, e.g., within an "if" or "foreverypart" block > (MIME). > 258 The included script SHALL NOT have any special control over the > 259 control structure it was included from, e.g., inclusion > from within a > 260 "foreverypart" block does not allow the included script > to directly > 261 terminate or continue flow of that block. I've been pondering on this a little while. As it is now, this only solves part of the ambiguity imho. For instance in RFC 5703 Section 4.1 the following alternatives (amongst others) are described: When used outside the context of a "foreverypart" 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 "foreverypart" iterator, and with an ":anychild" tagged argument, the "header" test will examine the current MIME part context and all its nested MIME body parts, returning true if any of them satisfies the test. So, imagine the following situation. require "foreverypart"; require "include"; foreverypart { if :mime :anychild "subject" "whatever" { include "included"; } } require "mime"; require "fileinto"; if header :mime :anychild :contenttype "Content-Type" "text/html" { fileinto "INBOX.html"; } So, what does this do? Which of the two alternatives described above is used? Is the header test in the "included" script executed in the context of "foreverypart" in the "toplevel" script or not, i.e. is the foreverypart context passed down to included scripts? In my opinion, this is still bit ambiguous in the current wording. From your reply I infer that the context is not passed down, but perhaps the text should mention that explicitly. It is not only about the influence the includED script may have on the loop in the includING script, but also about the influence in the other direction. Regards, Stephan. From iesg-secretary@ietf.org Tue Oct 18 09:05:29 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C70121F8C08; Tue, 18 Oct 2011 09:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83Igs7rE0KdU; Tue, 18 Oct 2011 09:05:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963B421F8C0B; Tue, 18 Oct 2011 09:05:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111018160528.9397.82509.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2011 09:05:28 -0700 Cc: sieve mailing list , sieve chair , RFC Editor Subject: [sieve] Protocol Action: 'Sieve Notification Mechanism: SIP MESSAGE' to Proposed Standard (draft-ietf-sieve-notify-sip-message-08.txt) X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:05:29 -0000 The IESG has approved the following document: - 'Sieve Notification Mechanism: SIP MESSAGE' (draft-ietf-sieve-notify-sip-message-08.txt) as a Proposed Standard This document is the product of the Sieve Mail Filtering Language Working Group. The IESG contact persons are Pete Resnick and Peter Saint-Andre. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sieve-notify-sip-message/ Technical Summary The Sieve scripting language is used to filter email messages. One action that can be executed on matching messages is sending of a notification, which can be sent using different mechanisms. This document describes a profile of the Sieve extension for notifications, to allow notifications to be sent over SIP MESSAGE. Working Group Summary This extension started as an individual submission in 2007 and was adopted as a WG document in 2008. The basic premise has remained the same throughout all revisions of the document. This extension adds an additional notification method to the SIEVE Notify extension (RFC5435) that enables use of SIP as a notification mechanism. There were no major issues with the SIEVE aspects of this extension, given experience with developing other notification mechanisms (already published as RFCs). The one major area of concern was the use of the SIP URI itself. Following an initial WG last call where this issue was brought up, the authors solicited reviews from relevant RAI area experts. The authors' documented the issues in the -03 draft for further WG discussions which resolved the issues, resulting in the current -04 document, which underwent another WG last call. Document Quality There are no known implementations of this extension at present. Various vendors have expressed interest in implementing this extension, however it is not currently a top priority for any of them. Personnel Document Shepherd: Cyrus Daboo AD: Pete Resnick From internet-drafts@ietf.org Tue Oct 18 12:34:13 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C57021F8DA5; Tue, 18 Oct 2011 12:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDsJDJ5X+der; Tue, 18 Oct 2011 12:34:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AE621F8D1B; Tue, 18 Oct 2011 12:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111018193412.18118.52284.idtracker@ietfa.amsl.com> Date: Tue, 18 Oct 2011 12:34:12 -0700 Cc: sieve@ietf.org Subject: [sieve] I-D Action: draft-ietf-sieve-convert-05.txt X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:34:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sieve Mail Filtering Language Working= Group of the IETF. Title : Sieve Extension for Converting Messages Before Delivery Author(s) : Alexey Melnikov Qian Sun Barry Leiba Kepeng Li Filename : draft-ietf-sieve-convert-05.txt Pages : 9 Date : 2011-10-18 This document describes how IMAP CONVERT can be used within Sieve to transform messages before final delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sieve-convert-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sieve-convert-05.txt From stephan@rename-it.nl Wed Oct 26 06:44:48 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CC021F8B0C for ; Wed, 26 Oct 2011 06:44:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbV1ZJHBOx6k for ; Wed, 26 Oct 2011 06:44:48 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id C723F21F8AEC for ; Wed, 26 Oct 2011 06:44:46 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:63280 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RJ3mV-0004SF-NO for sieve@ietf.org; Wed, 26 Oct 2011 15:44:41 +0200 Message-ID: <4EA80EB1.8050705@rename-it.nl> Date: Wed, 26 Oct 2011 15:44:17 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sieve mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Subject: [sieve] About editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 13:44:48 -0000 Hi, I've recently started implementing the editheader extension and based on the specification (RFC 5293) I have a few questions. (1) This is the first extension to introduce an action command with match arguments (match type and comparator), apart perhaps from the "denotify" command of the long-deprecated notify extension. Some match types such as ":matches" introduce the side-effect of setting match variables when the variables extension is active (RFC 5229; Section 3.2). So, my question is: can deleteheader action of the editheader extension affect match variables or is that supposed to be disabled much like the body test? Intuitively, I would think it is supposed to be disabled, i.e. I feel no action command should influence match variables. Also, it is not really possible to short-circuit the 'test' as required in RFC 5229 Section 3.2, because all matching headers must be deleted and thus matching continues. What do you think? (2) If I understand the specification correctly, users can use the editheader extension to (accidentally) create invalid IMAIL (now RFC 5322, was RFC 2822) messages. Some header fields defined in the IMAIL specification have a restricted number of occurrences and some have a specific well-defined structure. The editheader specification does not require, recommend, nor mention keeping the message a valid RFC2822 message. The only syntactic restriction I see is the requirement that the field value complies with the "unstructured" nonterminal syntax from IMAIL. It is allowed to silently refuse certain modifications (e.g. deleting Received headers), but I would have expected some recommendations in this respect. For example, is it wise to allow adding a second 'Subject:' header, or to allow setting the 'Date:' header to some syntactically incorrect nonsense? More complex examples would include the requirement for a 'Sender:' header when more than one 'From:' mailbox is specified. Syntax problems can be handled the same as deleting a restricted header (silently ignore), however, enforcing the uniqueness (and presence) of certain headers is a bit more complicated. Bluntly refusing addheader when the header already exists makes modifying such headers impossible, especially when deleting the header first would not be allowed (e.g. for 'Date:'; it is unique AND required). Implicitly deleting the previous occurrence of such headers during addheader would be an option, but is that a good idea? Or am I just exaggerating this problem? Regards, Stephan. From iesg-secretary@ietf.org Wed Oct 26 16:49:16 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64B21F0C54; Wed, 26 Oct 2011 16:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYkjsq+oCBG1; Wed, 26 Oct 2011 16:49:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A96A1F0C36; Wed, 26 Oct 2011 16:49:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111026234916.18059.98363.idtracker@ietfa.amsl.com> Date: Wed, 26 Oct 2011 16:49:16 -0700 Cc: sieve@ietf.org Subject: [sieve] Last Call: (Sieve Extension for Converting Messages Before Delivery) to Proposed Standard X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 23:49:16 -0000 The IESG has received a request from the Sieve Mail Filtering Language WG (sieve) to consider the following document: - 'Sieve Extension for Converting Messages Before Delivery' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how IMAP CONVERT can be used within Sieve to transform messages before final delivery. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sieve-convert/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sieve-convert/ No IPR declarations have been submitted directly on this I-D. From guenther+mtafilters@sendmail.com Wed Oct 26 19:10:34 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBBE21F8AB0 for ; Wed, 26 Oct 2011 19:10:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEqF4A1Y65ec for ; Wed, 26 Oct 2011 19:10:33 -0700 (PDT) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0993321F86A1 for ; Wed, 26 Oct 2011 19:10:32 -0700 (PDT) Received: from [10.210.202.4] ([10.210.202.4]) (authenticated bits=0) by spork.sendmail.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9R29rvH018983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2011 19:10:03 -0700 X-DKIM: Sendmail DKIM Filter v2.8.4 spork.sendmail.com p9R29rvH018983 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1319681404; bh=qEkXf/ne5GJfVA4B1j3iTxIdA8XCYHiG7Yu1ttKsj0E=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=B77jRsRK0sNXx9aMKMk023/APVb2t0kMrqNzSZCNnVG6w1wclVepY5qSoCDG5eWbz ftJXPEDLlPnz4Ds/MEpd5o3UXaF1iOdpEetQOfiEAt1JoLneNS09MrI4NseeyY9GBq 4qh4REBXJzK4qCWF2ESZQWaV5nhFRTEHn5ggIJMQ= X-DKIM: Sendmail DKIM Filter v2.8.4 spork.sendmail.com p9R29rvH018983 Date: Wed, 26 Oct 2011 19:09:53 -0700 From: Philip Guenther X-X-Sender: guenther@morgaine.smi.sendmail.com To: Stephan Bosch In-Reply-To: <4EA80EB1.8050705@rename-it.nl> Message-ID: References: <4EA80EB1.8050705@rename-it.nl> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-LogiQ-ip: WHITELIST:IP_WL.EXACT/p9R29rvH018983@spork.sendmail.com X-LogiQ-sender: UNKNOWN:UNKNOWN.UNKNOWN/p9R29rvH018983@spork.sendmail.com Cc: Sieve mailing list Subject: Re: [sieve] About editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 02:10:34 -0000 On Wed, 26 Oct 2011, Stephan Bosch wrote: > I've recently started implementing the editheader extension and based on the > specification (RFC 5293) I have a few questions. > > (1) > > This is the first extension to introduce an action command with match > arguments (match type and comparator), apart perhaps from the "denotify" > command of the long-deprecated notify extension. Some match types such > as ":matches" introduce the side-effect of setting match variables when > the variables extension is active (RFC 5229; Section 3.2). So, my > question is: can deleteheader action of the editheader extension affect > match variables or is that supposed to be disabled much like the body > test? ... It should affect match variables. The variables extension, when it describes the side-effect of the :matches match-type, places no restriction on it only affecting its use in tests and not in actions. As co-author of the RFC I can confirm that it was my intent that they do so and that the original implementation, as written by my co-author Jutta, certainly does set match variables. Note that the body test explictly calls out that variables aren't set, while no such statement appears in this RFC. > (2) > > If I understand the specification correctly, users can use the > editheader extension to (accidentally) create invalid IMAIL (now RFC > 5322, was RFC 2822) messages. Some header fields defined in the IMAIL > specification have a restricted number of occurrences and some have a > specific well-defined structure. The editheader specification does not > require, recommend, nor mention keeping the message a valid RFC2822 > message. The only syntactic restriction I see is the requirement that > the field value complies with the "unstructured" nonterminal syntax from > IMAIL. It is allowed to silently refuse certain modifications (e.g. > deleting Received headers), but I would have expected some > recommendations in this respect. For example, is it wise to allow adding > a second 'Subject:' header, or to allow setting the 'Date:' header to > some syntactically incorrect nonsense? More complex examples would > include the requirement for a 'Sender:' header when more than one > 'From:' mailbox is specified. I think this is completely up to local policy. There are implementations that operate in contexts where the 'message' that is being operated on is not required to meet all the requirements of RFC 5322. For a similar scenario, the IMAP standard's APPEND command merely says that an appended message "SHOULD be in the format of an [RFC-2822] message" and even provides an example of why a message might legitimately fail to be in that form later: Note: There MAY be exceptions, e.g., draft messages, in which required [RFC-2822] header lines are omitted in the message literal argument to APPEND. The full implications of doing so MUST be understood and carefully weighed. (IMO, using the RFC 2119 keywords "MAY" and "MUST" in that note was pointless. MUST be understood by whom? And how does 'understanding the implications' affect interoperability?) Personally, I'm a liberal on this: I think an implementation should let you do whatever you want in the script and only when the message goes 'out' (via a fileinto, redirect, the implicit keep, etc) should the format be checked in any way. The message format standard isn't a straight jacket, but rather a statement about what others are expected to accept and how they should interpret that. If you send something outside of that spec, you've gone outside the bounds of the standard and left your message open to rejection, modification, and misinterpretation...unless you have an agreement beyond the base standard. In other words: > Or am I just exaggerating this problem? In my opinion, yes. Philip Guenther From NED+mta-filters@mauve.mrochek.com Wed Oct 26 20:47:26 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B4B21F8A6C for ; Wed, 26 Oct 2011 20:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdBiGmPPfsuR for ; Wed, 26 Oct 2011 20:47:25 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C130421F8888 for ; Wed, 26 Oct 2011 20:47:25 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7OQ4WACWW013RXB@mauve.mrochek.com> for sieve@ietf.org; Wed, 26 Oct 2011 20:44:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7N65CXZS000RCTX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Wed, 26 Oct 2011 20:44:37 -0700 (PDT) From: NED+mta-filters@mauve.mrochek.com Message-id: <01O7OQ4SJQ7E00RCTX@mauve.mrochek.com> Date: Wed, 26 Oct 2011 20:18:37 -0700 (PDT) In-reply-to: "Your message dated Wed, 26 Oct 2011 15:44:17 +0200" <4EA80EB1.8050705@rename-it.nl> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4EA80EB1.8050705@rename-it.nl> To: Stephan Bosch Cc: Sieve mailing list Subject: Re: [sieve] About editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 03:47:26 -0000 > (1) > This is the first extension to introduce an action command with match > arguments (match type and comparator), apart perhaps from the "denotify" > command of the long-deprecated notify extension. Some match types such > as ":matches" introduce the side-effect of setting match variables when > the variables extension is active (RFC 5229; Section 3.2). So, my > question is: can deleteheader action of the editheader extension affect > match variables or is that supposed to be disabled much like the body test? I don't see why not. Our implementation certainly does. > Intuitively, I would think it is supposed to be disabled, i.e. I feel no > action command should influence match variables. My intuitation says exactly the opposite. And more to the point, the specifications seem very clear that :matches combined with variables sets match variables. It doesn't say only :matches in a test combined with variables set match variables AFAIK. > Also, it is not really > possible to short-circuit the 'test' as required in RFC 5229 Section > 3.2, because all matching headers must be deleted and thus matching > continues. Short-circuiting simply means you're supposed to stop as soon as possible and retain the last match. It's a moot statement when there's no stopping condition as with deleteheader, so I see no real conflict. > (2) > If I understand the specification correctly, users can use the > editheader extension to (accidentally) create invalid IMAIL (now RFC > 5322, was RFC 2822) messages. It can also be done intentionally. And there can be good reasons for doing so. Sieves are typically applied around the time of final delivery to the store, and all kinds of odd things hang off of message stores. And in point of fact, this is actually permitted by the relevant standards: Criteria for what's legal in a message store message are a lot more lax than RFC 5322 specifies. > Some header fields defined in the IMAIL > specification have a restricted number of occurrences and some have a > specific well-defined structure. The editheader specification does not > require, recommend, nor mention keeping the message a valid RFC2822 > message. The only syntactic restriction I see is the requirement that > the field value complies with the "unstructured" nonterminal syntax from > IMAIL. It is allowed to silently refuse certain modifications (e.g. > deleting Received headers), but I would have expected some > recommendations in this respect. I wouldn't and would oppose their addition. In fact in hindsight I think the MUST NOT allow deletion of Received: fields is actually a mistake. (Yes, I know it can be used to break loop detection, but it also can be used to work around bogus loop checks which, like it or not, do happen from time to time.) > For example, is it wise to allow adding > a second 'Subject:' header, or to allow setting the 'Date:' header to > some syntactically incorrect nonsense? The problem is figuring out where the boundary between what you should allow and what you shouldn't is nearly impossible to specify. And even if were, there's an even bigger problem: A series of editheader actions may at some intermediate point leave the header in an "illegal" condition that subsequent actions fix up. So if you want to try and prevent generation of "illegal" headers you have to look at the sum of the actions. Good luck with that. > More complex examples would > include the requirement for a 'Sender:' header when more than one > 'From:' mailbox is specified. A condition that could easily arise as an intermediate step in editing. > Syntax problems can be handled the same as deleting a restricted header > (silently ignore), however, enforcing the uniqueness (and presence) of > certain headers is a bit more complicated. Bluntly refusing addheader > when the header already exists makes modifying such headers impossible, > especially when deleting the header first would not be allowed (e.g. for > 'Date:'; it is unique AND required). Implicitly deleting the previous > occurrence of such headers during addheader would be an option, but is > that a good idea? No, for the reasons I've given. > Or am I just exaggerating this problem? Yes, I'd have to say that you are. Ned From arnt@gulbrandsen.priv.no Thu Oct 27 05:32:02 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BD221F85B5 for ; Thu, 27 Oct 2011 05:32:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qY9NidUdDOM for ; Thu, 27 Oct 2011 05:32:01 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E07F21F85B1 for ; Thu, 27 Oct 2011 05:31:59 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (kalyani.aox.org [79.140.39.164]) by strange.aox.org (Postfix) with ESMTP id 6431EFA0076; Thu, 27 Oct 2011 12:31:54 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1319718712-10719-10718/8/5; Thu, 27 Oct 2011 14:31:52 +0200 Message-Id: <4EA94F45.4060404@gulbrandsen.priv.no> Date: Thu, 27 Oct 2011 14:32:05 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Mime-Version: 1.0 To: sieve@ietf.org Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: [sieve] speaking as user: automatically printing incoming mail? X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 12:32:02 -0000 Hi, I (as mere user) get some mail for which I want to print the appended PDFs, and I'm not good at such chores. But wait, I'm using sieve and as we all know, script interpreters are really good at chores, maybe I can print with sieve? No I can't. Not only is there no implemented extension, but I also can't find any documented extension to print anything. Are there any vendor-specific extensions for such things? Arnt From NED+mta-filters@mauve.mrochek.com Thu Oct 27 07:48:43 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD7E21F88B6 for ; Thu, 27 Oct 2011 07:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=2.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh6TCBTFQ8Nc for ; Thu, 27 Oct 2011 07:48:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 362AF21F86D0 for ; Thu, 27 Oct 2011 07:48:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7PD7OYM8000WZR6@mauve.mrochek.com> for sieve@ietf.org; Thu, 27 Oct 2011 07:45:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01O7N65CXZS000RCTX@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Thu, 27 Oct 2011 07:45:49 -0700 (PDT) From: NED+mta-filters@mauve.mrochek.com Message-id: <01O7PD7KG4G000RCTX@mauve.mrochek.com> Date: Thu, 27 Oct 2011 07:43:42 -0700 (PDT) In-reply-to: "Your message dated Thu, 27 Oct 2011 14:32:05 +0200" <4EA94F45.4060404@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <4EA94F45.4060404@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: sieve@ietf.org Subject: Re: [sieve] speaking as user: automatically printing incoming mail? X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:48:43 -0000 > I (as mere user) get some mail for which I want to print the appended > PDFs, and I'm not good at such chores. But wait, I'm using sieve and as > we all know, script interpreters are really good at chores, maybe I can > print with sieve? > No I can't. Not only is there no implemented extension, but I also can't > find any documented extension to print anything. > Are there any vendor-specific extensions for such things? We typically handle such things by giving the printer an email address. Then all the Sieve has to do is redirect to that address when the user wants something printed. Ned From cyrus@daboo.name Thu Oct 27 07:54:23 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5C721F8B4A for ; Thu, 27 Oct 2011 07:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-s8ylbKj85C for ; Thu, 27 Oct 2011 07:54:22 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id C73FC21F8B48 for ; Thu, 27 Oct 2011 07:54:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 5E9651BEBEB3; Thu, 27 Oct 2011 10:54:22 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 571HY4qzvidZ; Thu, 27 Oct 2011 10:54:20 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 860321BEBEA7; Thu, 27 Oct 2011 10:54:19 -0400 (EDT) Date: Thu, 27 Oct 2011 10:54:16 -0400 From: Cyrus Daboo To: Arnt Gulbrandsen , sieve@ietf.org Message-ID: <67DC3F649EBF105601AE9D23@caldav.corp.apple.com> In-Reply-To: <4EA94F45.4060404@gulbrandsen.priv.no> References: <4EA94F45.4060404@gulbrandsen.priv.no> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=867 Subject: Re: [sieve] speaking as user: automatically printing incoming mail? X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:54:23 -0000 Hi Arnt, --On October 27, 2011 2:32:05 PM +0200 Arnt Gulbrandsen wrote: > I (as mere user) get some mail for which I want to print the appended > PDFs, and I'm not good at such chores. But wait, I'm using sieve and as > we all know, script interpreters are really good at chores, maybe I can > print with sieve? > > No I can't. Not only is there no implemented extension, but I also can't > find any documented extension to print anything. > > Are there any vendor-specific extensions for such things? Well there are things like email-to-printer gateways so a simple redirect in sieve could do that. I could also imagine defining a notification mechanism that makes use of the ipp: URI scheme (). This is the first time I have heard someone request such a feature though. -- Cyrus Daboo From barryleiba.mailing.lists@gmail.com Thu Oct 27 08:57:06 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF8021F8BA9 for ; Thu, 27 Oct 2011 08:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.92 X-Spam-Level: X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv+IwV2NoUr6 for ; Thu, 27 Oct 2011 08:57:05 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 61BCC21F8B87 for ; Thu, 27 Oct 2011 08:57:05 -0700 (PDT) Received: by ggnv1 with SMTP id v1so3276635ggn.31 for ; Thu, 27 Oct 2011 08:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7CG6xhea2BfC4mZDPz95lBR3MRoGY40sFgf4Jr6KqoE=; b=nWyiUKSOy5d7JksPU5mclhM/sJw8spHuXDScKLH3AaFCV45red51ut/HhxHZDlDSMP V9nEaTUPHmdmpMyDsLgBfwiwQNoOJyvjA+8D3sVB9bE3m+f2ynn7AQLr8TLqeFinEDCc 1VFZlgtD50aOMZVzGv2SlFKs8E/yl/EccCHGM= MIME-Version: 1.0 Received: by 10.236.87.136 with SMTP id y8mr3567460yhe.59.1319731025032; Thu, 27 Oct 2011 08:57:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.250.14 with HTTP; Thu, 27 Oct 2011 08:57:04 -0700 (PDT) In-Reply-To: <67DC3F649EBF105601AE9D23@caldav.corp.apple.com> References: <4EA94F45.4060404@gulbrandsen.priv.no> <67DC3F649EBF105601AE9D23@caldav.corp.apple.com> Date: Thu, 27 Oct 2011 11:57:04 -0400 X-Google-Sender-Auth: iqTrYBKBzjT1srPukYKV-dgvBjo Message-ID: From: Barry Leiba To: Cyrus Daboo Content-Type: text/plain; charset=ISO-8859-1 Cc: sieve@ietf.org Subject: Re: [sieve] speaking as user: automatically printing incoming mail? X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:57:06 -0000 > I could also imagine defining a notification mechanism > that makes use of the ipp: URI scheme > (). This is the first time I have > heard someone request such a feature though. I like that ideal. Arnt, I'll work on a Notify extension for that with you, if you like. Let me know. For the more general question, Wolfgang and I had once started to write up a "call out to an external process" extension, which would basically allow a script to run any (approved) program on the message, which could include an abuse scanner, an attachment filer, a printing or faxing program, or anything else. Our idea was that allowed programs would have to be flagged, such as by storing them in a particular place or putting their pathnames in certain metadata, to prevent chaos. But we never went anywhere with that, after the initial knocking about. Barry From stephan@rename-it.nl Thu Oct 27 10:04:28 2011 Return-Path: X-Original-To: sieve@ietfa.amsl.com Delivered-To: sieve@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1509621F8BB6 for ; Thu, 27 Oct 2011 10:04:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0hCme1gZvyA for ; Thu, 27 Oct 2011 10:04:27 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63021F8BB1 for ; Thu, 27 Oct 2011 10:04:26 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:63558 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RJTNL-0001PE-DZ; Thu, 27 Oct 2011 19:04:21 +0200 Message-ID: <4EA98EDE.9050700@rename-it.nl> Date: Thu, 27 Oct 2011 19:03:26 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ned Freed References: <4EA80EB1.8050705@rename-it.nl> <01O7OQ4SJQ7E00RCTX@mauve.mrochek.com> In-Reply-To: <01O7OQ4SJQ7E00RCTX@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Cc: Sieve mailing list Subject: Re: [sieve] About editheader X-BeenThere: sieve@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIEVE Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:04:28 -0000 On 10/27/2011 5:18 AM, Ned Freed wrote: >> Also, it is not really >> possible to short-circuit the 'test' as required in RFC 5229 Section >> 3.2, because all matching headers must be deleted and thus matching >> continues. > > Short-circuiting simply means you're supposed to stop as soon as > possible and > retain the last match. It's a moot statement when there's no stopping > condition as with deleteheader, so I see no real conflict. Yeah, now that you explain it like that, I agree. My main concern is consensus anyway. [...] >> Or am I just exaggerating this problem? > > Yes, I'd have to say that you are. And, apparently you're not the only one. Well, it's a good thing anyway; saves me quite a bit of work. ;) Thanks! Regards, Stephan