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@ietf.org
> https://www.ietf.org/mailman/listinfo/sieve