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

From: Thomas Schmid <[email-masked]>
Date: Fri, 12 Oct 2012 22:49:02 +0200

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 Bosch <[email-masked]>
Date: Fri, 12 Oct 2012 23:36:21 +0200

Hi Thomas,

On 10/12/2012 10:49 PM, Thomas Schmid wrote:
> 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.
>
> 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: [email-masked]
Date: Fri, 12 Oct 2012 16:40:59 -0700 (PDT)

> 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: Tim Showalter <[email-masked]>
Date: Fri, 12 Oct 2012 17:02:12 -0700

> 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 Bosch <[email-masked]>
Date: Sat, 13 Oct 2012 02:24:39 +0200

On 10/13/2012 1:40 AM, Ned Freed wrote:
> 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.

>    And good luck getting user agents to display additional header 

I think this is what he means to achieve by standardization, although I 
agree this would be quite futile.

> 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.