On Aug 24, 2010, at 7:05 AM, Stephan Bosch wrote:
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?
The cases would depend upon the particulars of the mechanism the implementation
used to notify the users. For instance, if an email server's sieve engine
notified by email, that email may simply not be deliverable (or sendable).
(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.
But this can be hard to determine. For instance, consider a script installed
on behalf of a user versus a script installed by that user. The sieve engine
cannot necessarily distinguish these two cases. This argues for a method for
specifying in the script how notifications are to handled.
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?
I'd suggest the header include indication of the nature of the error and an
optional URI where additional information about the error may be found.
- 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.
Off hand, the only case where I can think it appropriate to disable the script
is when the script would no longer be acceptable as a whole, such as require
statement failing at run time (which is possible due to changes in engine
support for extensions).
- 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
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve