ietf-mta-filters
[Top] [All Lists]

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

2010-08-24 08:16:03

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