Re: [sieve] Script Runtime errors via X-Headers

NED+mta-filters@mauve.mrochek.com Fri, 12 October 2012 23:56 UTC

Return-Path: <NED+mta-filters@mauve.mrochek.com>
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 <sieve@ietfa.amsl.com>; 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 <sieve@ietfa.amsl.com>; 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 <sieve@ietf.org>; 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
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 <stephan@rename-it.nl>
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 <sieve.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sieve>, <mailto:sieve-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sieve>
List-Post: <mailto:sieve@ietf.org>
List-Help: <mailto:sieve-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sieve>, <mailto:sieve-request@ietf.org?subject=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