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

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

2010-08-24 09:48:10

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