[Top] [All Lists]

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

2010-08-28 00:52:52
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.)

Yes, quoting problems are probably the most common source of incorrectly
constructed sieves.

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". :)

That's a very interesting observation. The reason it works this way is that
we're in the middle of processing the message for delivery when the error
occurs. The error message is a separate message, and it has to be enqueued and
undergo regular message processing, so it's pretty much guaranteed to arrive

I'll give some thought to how to change this behavior, but right now I don't
see a way to do it that wouldn't involve doing something fairly nasty to delay
the original message. And even then there's no guatantee that this will result
in the "correct" order.

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.

Also an interesting idea, but my reading of RFC 5228 says this violates the
MUST at the end of section 2.10.6. That said, the case in our implementation
where errors are most likely is actually in the system-level Sieves that are
typically hand-constructed by admins, and in this context a system log _is_
visible to the "user" who owns the incorrect filter. So in this case the RFC
isn't being violated. And this is also the case that's most likely to lead to
an excessive number of error notifications.

In other words, this sounds like a good feature to implement for system-level
sieves at least. Thanks for the suggestion!

sieve mailing list

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