Hello,
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
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."
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.
Regards,
Stephan
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve
----- End message from stephan(_at_)rename-it(_dot_)nl -----
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve