[Top] [All Lists]

Re: [sieve] Poll: how to report Sieve runtime errors to the user?

2010-08-24 18:52:37

On Aug 24, 2010 at 18:49 -0400, Barry Leiba wrote:
=>> not people don't even understand that Sieve is what underlies all 
=>> this, they don't understand what messages saying stuff like 
=>> "fileinto used without first being activated with a require or 
=>> ihave" mean.)
=>Indeed.  Telling an end user that her sieve script had an error is
=>somewhat like asking an end user what she wants the browser to do with
=>a security certificate problem: it's a WTF? situation.

As an operator...yup.  Most just want it fixed.

=>I really think that Kurt and Ned are saying the same thing here: when
=>Kurt says that "do an implicit KEEP is enough of an indication that
=>something's wrong," he's saying what Ned means when he says "I'm not
=>convinced this is a problem we need to deal with."
=>I agree with them.  Perhaps if we revise 5228, at some point, we can
=>change the MUST in the sort of manner that Kurt suggests, but maybe
=>aim it more at informing an administrator, rather than a user, and add
=>some vague statement about the method of informing being up to the
=>implementation, but implementations should keep in mind that it's a
=>Bad Idea to complain to users about things they won't understand.

As an operator of Ned's implementation I like the user getting a error 
e-mail as it then prompts the user to do 1) nothing, 2) figure out the 
problem themselves, or 3) contact our support desk.  As Ned mentioned, 
users construct their filters via a web interface that should not make 
syntacticly incorrect filters, but we did have a while were a single quote 
(') in a certain field was not escaped correctly by the web interface 
and it caused a "broken" filter.  (This was a couple of years ago.)  I 
fixed the user's filter by hand when a support case was opened.  (I 
don't remember if I ever went looking in the server logs as the admin to 
see if I could proactively fix filters for users that did nothing.)

The only part that I would have liked to see done differently was that 
the "notice/error" e-mail message be delivered BEFORE the implicit KEEP 
message.  As it was delivered after, I would get a question like "Why 
are you notify me about a message I already got?"  But, then you have 
started to enter the user's "WTF? situation". :)

So, make it a admin choice.  If they want their user's notified, great.  
If not, the implementation should still be logging it somewhere for the 
admin so see.

Derek Diget                            Office of Information Technology
Western Michigan University - Kalamazoo  Michigan  USA -
sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>