[Top] [All Lists]

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

2010-08-24 09:06:10
 Hi Kurt,

Op 24-8-2010 15:15, Kurt Zeilenga wrote:
On Aug 24, 2010, at 3:10 AM, Stephan Bosch wrote:
"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."
Personally, the first part (before the "and") is an improper MUST IMO as it 
fails to take into consideration the various cases in which an implementation cannot 
notify the user.

Could you provide examples of such cases?

(It also not terribly clear what "user" is being referred to here.  If a email 
domain administrator installed script fails, does the error notice go the email domain 
administrator, system operator, the owner of the email account, or combination thereof?)

Good question. My current approach is to report the error to whomever has or could have caused it and/or should fix it.

I think one could argue that "implicit keep"ing the message is itself a form of 
notification.  For instance, if I have a rule that does a fileinto that cannot be 
processed (e.g., mbox doesn't exist), having the message stored in my inbox can be an 
effective notification that an error occurred in the processing the fileinto.

Right, but then the act of finding the cause of the problem remains an issue. It would be quite cumbersome if users need to ask (bug) the administrator for assistance when they produce bugs in their own Sieve scripts. Some form of access to the actual error messages for the users is desirable at least.

The alternative approaches/ideas I've seen/had thus far include:
  - log the error, expose logs to script authors.

And for notification, maybe in addition to "implicit keep", add a special header to the 
message.  But personally "implicit keep" (or bounce if not keepable) is enough 
notification for me.

Ok, this pertains to my remark above. How do you 'expose the logs to script authors'. A web interface of some sorts? Would your proposed header contain the error message or just a status flag?

- disable the offending script and e-mail the script owner to report that there 
was an error, and that their script is disabled until they go and fix it (Barry)
Yikes!  The script might just have a run-time error hit only when a particular 
condition is true.  Disabling the entire script would be a bad thing.  I argue 
the script should be left in force.

If I remember correctly, this strategy was followed for 'fatal' errors only. Not sure what is considered a fatal error in this case. I think Barry can explain this in more detail.

- file a message containing the error report, e.g. in a special IMAP folder, 
for each failed delivery. Clearly, this can explode into a large number of 
messages when the script is fundamentally broken. This needs some mechanism to 
avoid reporting the identical problem for subsequent deliveries.
If the error is "disk full", likely the special folder will also be "disk 
full"... (and the implicit keep will also likely fail).  Log and bounce.

Good point, but this is a special case that can be handled separately (and if it is not quota-related it cannot be solved by the user anyway).


sieve mailing list