[Top] [All Lists]

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

2010-08-27 16:20:28

in my case the best option is to send email to the user, notifying about the error. The users do not have mailboxes on my server, just aliases, so when an error occurs and I mail them, there shall be no problem with delivering the error message.

In my case the scripts are executed during SMTP time, not final delivery, and the most common actions are stop, reject or keep, with vacation being the only other possible action. The point is that implicit keep is not always good: it could be smtp rejected by the subsequent mail servers -> bounced by my server (but I have no better ideas that implicit keep in case the script is broken).

Greetings, Dilian

----- Message from stephan(_at_)rename-it(_dot_)nl ---------
    Date: Tue, 24 Aug 2010 12:10:47 +0200
    From: Stephan Bosch <stephan(_at_)rename-it(_dot_)nl>
 Subject: [sieve] Poll: how to report Sieve runtime errors to the user?
      To: sieve(_at_)ietf(_dot_)org


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."

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:

- 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) - 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. - extend ManageSieve with a means to get notified about runtime errors and a means to retrieve (and possibly configure) runtime logs.



sieve mailing list

----- End message from stephan(_at_)rename-it(_dot_)nl -----

sieve mailing list