On Aug 24, 2010, at 3:10 AM, Stephan Bosch wrote:
Hi,
I attended the last meeting in Maastricht through XMPP. As I explained
there, I feel that something is currently missing in the Sieve world: a
standard means of handling and reporting runtime errors to the user. It was
suggested to ask around how people currently implement this and, possibly,
write up a best-practices document. I promised to perform this task, since I
was the one coining the issue in the first place. Now I finally have the time
to put this on the list.
Concretely, I'm talking about the implementation of the following requirement
in RFC5228, at the end of Section 2.10.6:
"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. (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?)
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.
I would suggest that upon revision of this spec, "MUST notify the user ... and
do an implicit keep" be changed to "SHOULD notify the script author ... and
MUST, if possible, do an implicit keep".
The RFC doesn't specify how this is to be implemented and, particularly for
virtual users, this is an interesting design problem. Therefore, I would like
to invite implementors on this list to report their current approach. We can
then discuss the benefits and limitations of the various reported
implementations and exchange ideas on possible alternatives.
The reason I brought this up is that my own implementation is currently very
limited and unsuitable for virtual users: it writes an error log file in the
directory where the main active script is located (typically in the user home
directory).
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.
- 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.
- 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.
- extend ManageSieve with a means to get notified about runtime errors and a
means to retrieve (and possibly configure) runtime logs.
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