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).
Regards,
Stephan.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve