From stephan@rename-it.nl Wed Oct 10 13:20:01 2012 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 B77A921F85C3 for ; Wed, 10 Oct 2012 13:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUBWJ3sJqlM0 for ; Wed, 10 Oct 2012 13:20:01 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id DEC6421F85A2 for ; Wed, 10 Oct 2012 13:19:59 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:51446 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 1TM2kw-0001mB-A4; Wed, 10 Oct 2012 22:19:52 +0200 Message-ID: <5075D84B.8030007@rename-it.nl> Date: Wed, 10 Oct 2012 22:19:23 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Barry Leiba References: <20120915020634.9588.76361.idtracker@ietfa.amsl.com> 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@ietf.org Subject: Re: [sieve] I-D Action: draft-ietf-sieve-imap-sieve-09.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: Wed, 10 Oct 2012 20:20:01 -0000 On 9/15/2012 2:33 PM, Barry Leiba wrote: > It looks like this is the final version that will go to the RFC > Editor. Just a question, how are we going to handle the approval of the following IMAP extension? https://tools.ietf.org/html/draft-ietf-imapmove-command-01 Intuitively, I would say that adds a new imap.cause item called "MOVE" and I guess at some point this (or something else) would need to be documented. Would it still be possible for the editor to hammer it into the current yet-to-be-RFC imapsieve document if IMAP MOVE (somehow) makes it to RFC first? Regards, Stephan. From aaron@serendipity.cx Wed Oct 10 13:34:18 2012 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 5087421F85A4 for ; Wed, 10 Oct 2012 13:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.193 X-Spam-Level: X-Spam-Status: No, score=-101.193 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HON4iUvK0JD2 for ; Wed, 10 Oct 2012 13:34:17 -0700 (PDT) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9421F859F for ; Wed, 10 Oct 2012 13:34:10 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by slice.serendipity.cx (Postfix) with ESMTPSA id C9CD194002 for ; Wed, 10 Oct 2012 13:29:52 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so1110134pbb.31 for ; Wed, 10 Oct 2012 13:33:52 -0700 (PDT) Received: by 10.68.213.1 with SMTP id no1mr60164803pbc.123.1349901232051; Wed, 10 Oct 2012 13:33:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.51.69 with HTTP; Wed, 10 Oct 2012 13:33:31 -0700 (PDT) In-Reply-To: <5075D84B.8030007@rename-it.nl> References: <20120915020634.9588.76361.idtracker@ietfa.amsl.com> <5075D84B.8030007@rename-it.nl> From: Aaron Stone Date: Wed, 10 Oct 2012 13:33:31 -0700 Message-ID: To: Stephan Bosch Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , sieve@ietf.org Subject: Re: [sieve] I-D Action: draft-ietf-sieve-imap-sieve-09.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: Wed, 10 Oct 2012 20:34:18 -0000 On Wed, Oct 10, 2012 at 1:19 PM, Stephan Bosch wrote: > On 9/15/2012 2:33 PM, Barry Leiba wrote: >> >> It looks like this is the final version that will go to the RFC >> Editor. > > > Just a question, how are we going to handle the approval of the following > IMAP extension? > > https://tools.ietf.org/html/draft-ietf-imapmove-command-01 > > Intuitively, I would say that adds a new imap.cause item called "MOVE" and I > guess at some point this (or something else) would need to be documented. > Would it still be possible for the editor to hammer it into the current > yet-to-be-RFC imapsieve document if IMAP MOVE (somehow) makes it to RFC > first? IMAP Sieve is already in the Editor's Queue, so it's surely ahead of IMAP MOVE. IMAP MOVE itself says that the command is equivalent to: """ The UID MOVE command has the same effect as a sequence of UID COPY, UID STORE +FLAGS.SILENT \DELETED and UID EXPUNGE ... """ One could argue that "copy" is a viable value for imap.cause. Aaron From barryleiba@gmail.com Wed Oct 10 13:45:32 2012 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 98C3521F854C for ; Wed, 10 Oct 2012 13:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSZ2apMQD8Gc for ; Wed, 10 Oct 2012 13:45:30 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD9F21F852C for ; Wed, 10 Oct 2012 13:45:30 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id fl11so1456846vcb.31 for ; Wed, 10 Oct 2012 13:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8Rzh7rAVFb3Wc6tOrrss0T+ubP6+L0RiaMnFSmtDco4=; b=dAG5+XCiiCYAITo1lBzZCU7zNxcatIKADuZKi00XZmU59YcksC182I786309OHESVc 5zf15GicrKtgUoleyonZnvvmVtYZm7HOIdVj38n38AD5/RKLzVg6DtnrsBdhiBgKRgSM O1c+0QAx7TJMS129X/27upY69QVDLPK9zuWTCBOiIuwkKoNvXS2WpJnlmJqdf5RYtAg6 q5wfN6m+LsNKgZY37Onsu79jCdQXnMEbRzail7z6MI9RwH0P/nBNqDaa3FImIUvsTypr ngi9mzYwfzZYqMZKzpN+B5P1vRjiVg85ga3gJhcrlbcuqco0fkyBBIUdmm2vDwVmVXp4 NUlg== MIME-Version: 1.0 Received: by 10.52.65.51 with SMTP id u19mr11883611vds.3.1349901929949; Wed, 10 Oct 2012 13:45:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.59.5.72 with HTTP; Wed, 10 Oct 2012 13:45:29 -0700 (PDT) In-Reply-To: References: <20120915020634.9588.76361.idtracker@ietfa.amsl.com> <5075D84B.8030007@rename-it.nl> Date: Wed, 10 Oct 2012 16:45:29 -0400 X-Google-Sender-Auth: yvEH7x-Rl5rvYEUblFoddynajqo Message-ID: From: Barry Leiba To: Aaron Stone Content-Type: text/plain; charset=ISO-8859-1 Cc: sieve@ietf.org Subject: Re: [sieve] I-D Action: draft-ietf-sieve-imap-sieve-09.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: Wed, 10 Oct 2012 20:45:32 -0000 >> Just a question, how are we going to handle the approval of the following >> IMAP extension? >> >> https://tools.ietf.org/html/draft-ietf-imapmove-command-01 >> >> Intuitively, I would say that adds a new imap.cause item called "MOVE" and I >> guess at some point this (or something else) would need to be documented. >> Would it still be possible for the editor to hammer it into the current >> yet-to-be-RFC imapsieve document if IMAP MOVE (somehow) makes it to RFC >> first? > > IMAP Sieve is already in the Editor's Queue, so it's surely ahead of IMAP MOVE. Right, and I've addressed this in my AD review of the MOVE extension document: http://www.ietf.org/mail-archive/web/imapext/current/msg04712.html ------------------------------ -- Section 4 -- Add a new Section: 4.5. IMAP Events in Sieve MOVE applies to IMAP events in Sieve [reference] in the same way as COPY does. Therefore, MOVE can cause a Sieve script to be invoked with the imap.cause set to "COPY". Because MOVE does not cause flags to be changed, a MOVE command will not result in a script invocation with the imap.cause set to "FLAG". The [reference] for IMAP Events in Sieve is draft-ietf-sieve-imap-sieve-09, which should be in the RFC Editor queue any day now (so it won't hold this document up). ------------------------------ ...with follow-up here: http://www.ietf.org/mail-archive/web/imapext/current/msg04714.html ------------------------------ Ned's comment: > I think this is the right thing to do, but I have to ask: Given the timing > of the Sieve in IMAP spec we could define a new "MOVE" cause in the base > specification if we wanted to. Do we want to do this? I thought about that when I wrote the above, and I can't find a good reason to distinguish MOVE from COPY in imap-sieve. It also wouldn't be as simple as just defining a new cause: we'd have to decide whether only the target-mailbox script is run, or whether the source-mailbox script is run as well. My sense is that it's not an important distinction, and we don't want to go there. ------------------------------ Barry From stephan@rename-it.nl Fri Oct 12 04:47:28 2012 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 0834521F844F for ; Fri, 12 Oct 2012 04:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.054 X-Spam-Level: X-Spam-Status: No, score=-0.054 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng5kZj-mw4YB for ; Fri, 12 Oct 2012 04:47: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 7835C21F853B for ; Fri, 12 Oct 2012 04:47:26 -0700 (PDT) Received: from ewi1299.ewi.utwente.nl ([130.89.145.113]:55522) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TMdi5-0005bO-Qp for sieve@ietf.org; Fri, 12 Oct 2012 13:47:24 +0200 Message-ID: <50780343.9050302@rename-it.nl> Date: Fri, 12 Oct 2012 13:47:15 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: sieve@ietf.org References: <20120915020634.9588.76361.idtracker@ietfa.amsl.com> <5075D84B.8030007@rename-it.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: Re: [sieve] I-D Action: draft-ietf-sieve-imap-sieve-09.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, 12 Oct 2012 11:47:28 -0000 Op 10/10/2012 10:45 PM, Barry Leiba schreef: >>> Just a question, how are we going to handle the approval of the following >>> IMAP extension? >>> >>> https://tools.ietf.org/html/draft-ietf-imapmove-command-01 >>> >>> Intuitively, I would say that adds a new imap.cause item called "MOVE" and I >>> guess at some point this (or something else) would need to be documented. >>> Would it still be possible for the editor to hammer it into the current >>> yet-to-be-RFC imapsieve document if IMAP MOVE (somehow) makes it to RFC >>> first? >> IMAP Sieve is already in the Editor's Queue, so it's surely ahead of IMAP MOVE. > Right, and I've addressed this in my AD review of the MOVE extension document: > http://www.ietf.org/mail-archive/web/imapext/current/msg04712.html I must have missed that one, because I am subscribed to that list. > I thought about that when I wrote the above, and I can't find a good > reason to distinguish MOVE from COPY in imap-sieve. It also wouldn't > be as simple as just defining a new cause: we'd have to decide whether > only the target-mailbox script is run, or whether the source-mailbox > script is run as well. My sense is that it's not an important > distinction, and we don't want to go there. I agree. Regards, Stephan. From schmid-thomas@gmx.net Fri Oct 12 13:49:08 2012 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 AA70921F8779 for ; Fri, 12 Oct 2012 13:49:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XF5+lMFjKBb for ; Fri, 12 Oct 2012 13:49:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 55D7B21F876A for ; Fri, 12 Oct 2012 13:49:04 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2012 20:49:02 -0000 Received: from dslb-088-067-182-072.pools.arcor-ip.net (EHLO [192.168.178.29]) [88.67.182.72] by mail.gmx.net (mp027) with SMTP; 12 Oct 2012 22:49:02 +0200 X-Authenticated: #550355 X-Provags-ID: V01U2FsdGVkX18jeCtPtcUjpEBrUVG5MTlymGZlsbGMu+LsbLj/5r g7cTYGUDYhauVV Message-ID: <5078823E.8030403@gmx.net> Date: Fri, 12 Oct 2012 22:49:02 +0200 From: Thomas Schmid User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:19.0) Gecko/19.0 Thunderbird/19.0a1 MIME-Version: 1.0 To: sieve@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [sieve] Script Runtime errors via X-Headers 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, 12 Oct 2012 20:49:08 -0000 Hi, recently I stumbled upon a server, which returns run time errors of a sieve script as an X-Header. I did not find any documentation regarding this behavior, so I think it non standard. Never the less it's quite handy. Especially if you move, rename or misspell an imap folder. Such an error X-Header looks like this: X-Nemesis-Sieve: missing mailbox "\example" Is there a chance to standardize this within the Sieve RFCs? It makes debugging script for inexperienced users with no access to the server logs way easier. Especially since Paragraph "2.10.6. Errors" of "rfc5228" requires implementation to represent script errors to the user but does not offer any suggestions how to do that. Thus I would suggest adding the following to paragraph 2.10.6 : When an error happens, implementations MUST notify the user that an error occurred and which actions (if any) were taken, and do an implicit keep. + This can be achieved by adding an "X-Sieve-Error" header containing + the runtime error message to the mail. What are your thought on that? Regards Thomas Schmid From stephan@rename-it.nl Fri Oct 12 14:37:15 2012 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 DB33621F8748 for ; Fri, 12 Oct 2012 14:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoRaJ6NXiJVK for ; Fri, 12 Oct 2012 14:37:15 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9121F8746 for ; Fri, 12 Oct 2012 14:37:11 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:60609 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 1TMmuo-0008AP-Tz; Fri, 12 Oct 2012 23:37:09 +0200 Message-ID: <50788D55.3070609@rename-it.nl> Date: Fri, 12 Oct 2012 23:36:21 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Thomas Schmid References: <5078823E.8030403@gmx.net> In-Reply-To: <5078823E.8030403@gmx.net> 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@ietf.org Subject: Re: [sieve] Script Runtime errors via X-Headers 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, 12 Oct 2012 21:37:16 -0000 Hi Thomas, On 10/12/2012 10:49 PM, Thomas Schmid wrote: > recently I stumbled upon a server, which returns run time errors of a > sieve script as an X-Header. I did not find any documentation > regarding this behavior, so I think it non standard. Never the less > it's quite handy. Especially if you move, rename or misspell an imap > folder. > > Such an error X-Header looks like this: > X-Nemesis-Sieve: missing mailbox "\example" > > Is there a chance to standardize this within the Sieve RFCs? It makes > debugging script for inexperienced users with no access to the server > logs way easier. > > Especially since Paragraph "2.10.6. Errors" of "rfc5228" requires > implementation to represent script errors to the user but does not > offer any suggestions how to do that. [...] > What are your thought on that? Actually, we had a discussion about this a few years ago: https://www.ietf.org/mail-archive/web/sieve/current/msg04799.html Regards, Stephan. From NED+mta-filters@mauve.mrochek.com Fri Oct 12 16:56:45 2012 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 8383721F86D9 for ; Fri, 12 Oct 2012 16:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glUSqC6+i8FL for ; Fri, 12 Oct 2012 16:56:45 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1754421F86D8 for ; Fri, 12 Oct 2012 16:56:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLC8KLJN4W0000QV@mauve.mrochek.com> for sieve@ietf.org; Fri, 12 Oct 2012 16:51:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLBVPEEW2O00008S@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for sieve@ietf.org; Fri, 12 Oct 2012 16:51:40 -0700 (PDT) From: NED+mta-filters@mauve.mrochek.com Message-id: <01OLC8KK2WWK00008S@mauve.mrochek.com> Date: Fri, 12 Oct 2012 16:40:59 -0700 (PDT) In-reply-to: "Your message dated Fri, 12 Oct 2012 23:36:21 +0200" <50788D55.3070609@rename-it.nl> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <5078823E.8030403@gmx.net> <50788D55.3070609@rename-it.nl> To: Stephan Bosch Cc: sieve@ietf.org Subject: Re: [sieve] Script Runtime errors via X-Headers 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, 12 Oct 2012 23:56:45 -0000 > Hi Thomas, > On 10/12/2012 10:49 PM, Thomas Schmid wrote: > > recently I stumbled upon a server, which returns run time errors of a > > sieve script as an X-Header. I did not find any documentation > > regarding this behavior, so I think it non standard. Never the less > > it's quite handy. Especially if you move, rename or misspell an imap > > folder. > > > > Such an error X-Header looks like this: > > X-Nemesis-Sieve: missing mailbox "\example" > > > > Is there a chance to standardize this within the Sieve RFCs? It makes > > debugging script for inexperienced users with no access to the server > > logs way easier. > > > > Especially since Paragraph "2.10.6. Errors" of "rfc5228" requires > > implementation to represent script errors to the user but does not > > offer any suggestions how to do that. > [...] > > What are your thought on that? > Actually, we had a discussion about this a few years ago: > https://www.ietf.org/mail-archive/web/sieve/current/msg04799.html I don't think adding headers was mentioned as part of that discussion, but FWIW, the header approach is a total nonstarter for us, for two reasons: (1) Only a *tiny* minority of users see the full message header. In fact a significant number of users have no idea how to get this information from their user agent even if they somehow knew to look for it. And good luck getting user agents to display additional header information like this by default. (2) This approach only works when the person responsible for the sieve content is the same as the message recipient. In our case the two are often different, and moreover the chance of a sieve runtime error is strongly inversely correlated with the two being the same. The somewhat feature of using a special header is that it eliminates the risk of getting deluged with error message reports. But we have many millions of end user sieves deployed, and we've had no reports of this happening. (And I think it likely we would have heard if it had happened.) Ned From tjs@psaux.com Fri Oct 12 17:02:17 2012 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 A3F6821F86A8 for ; Fri, 12 Oct 2012 17:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO9NtGT9Ivgm for ; Fri, 12 Oct 2012 17:02:16 -0700 (PDT) Received: from smtp103.prem.mail.sp1.yahoo.com (smtp103.prem.mail.sp1.yahoo.com [98.136.44.58]) by ietfa.amsl.com (Postfix) with SMTP id D3EFE21F86A4 for ; Fri, 12 Oct 2012 17:02:16 -0700 (PDT) Received: (qmail 33192 invoked from network); 13 Oct 2012 00:02:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1350086532; bh=UVezaukZm5/6OjNpu+3dUv6y5hXYs9dM99YQ4joUXHg=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=V+lwmSA7l/6dLudVoZSKpfc5UgJGW9/wmC6KdI2tDd2X/DXHWCaWuZ4hPkOQo8JJqYdtwzZq1OhzdbxkPu8QYhCHjrt0UonROS4p7RrCDnPi5ik7QscQO9fM8FzJpbQm4WrWwLVcyt7IoQsF0gWlHLLSSIOsArlpvwbYv8d5gys= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BiARaBcVM1ltLdKxKa4_mOnU5apd5NrUvZYAPlsg.A_2CYu hIHoh3SxCZxS93WkjBsH4rFxLFthhAo1Qo8Zv4_niFn2WYuZiyBUYF1oX2ab RhYzvtlrWlLOUvYi.OYFxn8WffXSMOk4ancVOnvMkQz78O5Cwtil949vTqJT uPmFCQQXZzUwfhFalzCbzdmf26RKPAXzIrDBp8rYMBtr4.kR16bvhmmvepOM vN8UF9TDaooMVQbzJ5ANm1lUmLOo2hneTNVfAcoIjblk55Td_7hPicOHyvcT vtr2ELvlYkSAs0LItqV8iUmMbPvCSqPzAwRJCs9x3DPRMOmO9oB3slOb30VV AFMInd.ie3aNi0o386Cw3OpoaWw3d_8AaxI0BpkpuR7iIeEQPgo1_f6f8oBS QEiDfJQo6KsHYCeA.4Ae65j_nDrdfrRF6rITPRBHigBVj8IpnLUJ5wQMqHNX qCQ-- X-Yahoo-SMTP: jK5ghcGswBAlBjVhZO0ppd4- Received: from bgai-mn(2).linkedin.biz (tjs@69.28.149.29 with plain) by smtp103.prem.mail.sp1.yahoo.com with SMTP; 12 Oct 2012 17:02:12 -0700 PDT Message-ID: <5078AF84.6050602@psaux.com> Date: Fri, 12 Oct 2012 17:02:12 -0700 From: Tim Showalter User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: sieve@ietf.org References: <5078823E.8030403@gmx.net> In-Reply-To: <5078823E.8030403@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sieve] Script Runtime errors via X-Headers 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: Sat, 13 Oct 2012 00:02:17 -0000 On 10/12/12 1:49 PM, Thomas Schmid wrote: > Thus I would suggest adding the following to paragraph 2.10.6 : > > When an error happens, implementations MUST notify the user that an > error occurred and which actions (if any) were taken, and do an > implicit keep. > > + This can be achieved by adding an "X-Sieve-Error" header containing > + the runtime error message to the mail. > > What are your thought on that? The original target for Sieve supported a multi-user server with a single-instance store, such that a message to N people need only be stored once. The server had already committed the message to disk before it was handled by filtering. So it was too late to write the header, and as the header was potentially shared between multiple users, it wasn't the place to put the data, either. Sneaking data into headers is a hack. It may be the best choice for some implementations, but it's not what headers are for. Tim From stephan@rename-it.nl Fri Oct 12 17:25:33 2012 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 2F41D21F86B3 for ; Fri, 12 Oct 2012 17:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.449 X-Spam-Level: X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MISSING_HEADERS=1.292, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJMTovGYEvhD for ; Fri, 12 Oct 2012 17:25:32 -0700 (PDT) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1F21F8607 for ; Fri, 12 Oct 2012 17:25:31 -0700 (PDT) Received: from klara.student.utwente.nl ([130.89.162.218]:61429 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 1TMpXk-0002c0-Bq for sieve@ietf.org; Sat, 13 Oct 2012 02:25:30 +0200 Message-ID: <5078B4C7.7080401@rename-it.nl> Date: Sat, 13 Oct 2012 02:24:39 +0200 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 CC: sieve@ietf.org References: <5078823E.8030403@gmx.net> <50788D55.3070609@rename-it.nl> <01OLC8KK2WWK00008S@mauve.mrochek.com> In-Reply-To: <01OLC8KK2WWK00008S@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -1.0 (-) X-RenameIT-MailScanner-SpamCheck: No, score=-1.0 required=5.0 tests=ALL_TRUSTED, BAYES_00, MISSING_HEADERS, SARE_MILLIONSOF autolearn=no version=3.3.1 Subject: Re: [sieve] Script Runtime errors via X-Headers 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: Sat, 13 Oct 2012 00:25:33 -0000 On 10/13/2012 1:40 AM, Ned Freed wrote: > Actually, we had a discussion about this a few years ago: > >> https://www.ietf.org/mail-archive/web/sieve/current/msg04799.html > > I don't think adding headers was mentioned as part of that discussion, > [...] FYI: https://www.ietf.org/mail-archive/web/sieve/current/msg04800.html It's mentioned there somewhere and also discussed in follow-up messages. > > (1) Only a *tiny* minority of users see the full message header. In > fact a > significant number of users have no idea how to get this information > from their user agent even if they somehow knew to look for it. > > And good luck getting user agents to display additional header > information > like this by default. I think this is what he means to achieve by standardization, although I agree this would be quite futile. > (2) This approach only works when the person responsible for the sieve > content > is the same as the message recipient. In our case the two are often > different, and moreover the chance of a sieve runtime error is > strongly > inversely correlated with the two being the same. > > The somewhat feature of using a special header is that it eliminates > the risk > of getting deluged with error message reports. But we have many > millions of end > user sieves deployed, and we've had no reports of this happening. (And > I think > it likely we would have heard if it had happened.) As was mentioned in the original discussion, the need and benefit for showing runtime errors to users that have created their Sieve scripts through some kind of GUI is very limited. In fact, it would likely confuse such users. The only convincing benefit mentioned was that users could provide more detailed information in their support questions directed at the helpdesk. For advanced users that directly write their own Sieve scripts this would be a quite different story, but apparently this situation is quite rare. Regards, Stephan.