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

[Stephan Bosch <[e-mail]>]

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.