[Top] [All Lists]

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

2010-08-24 10:41:56
 Hi Ned,

Op 24-8-2010 16:35, Ned Freed wrote:
It is important to keep in mind that Sieve errors are, or should be, pretty rare in practice. A lot of Sieves - in our case virtually all of then - are automatically generated, and an automatic generator should not be generating
broken Sieves.


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

I don't know what a "virtual user" is or why being one makes error handling
difficult, ...

Virtual users are those that are no actual system users and therefore (typically) have no shell, ftp etc. access to the system. My log files are thus not available to virtual users. Providing access to these logs would require some more effort (given that these are currently not mailed to the users).

... but FWIW, in our implementation every Sieve script has an associated
"responsible address". For a user Sieve this is simply the user's own address, for Sieves associated with an entire domain it's the domain postmaster, for system Sieves it's an administrator address. If there's an error, it's reported
by sending a message to the responsible address, whatever it may be. Such
messages are themselves exempted from Sieve processing, which prevents loops.

Right, that is sensible. However, in the arguably rare but not impossible case that a single Sieve frequently fails with a runtime error caused by a single problem, a message is sent to the responsible person on each failed delivery. I think this situation should be accounted for somehow.

- 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)

Disabling the Sieve in the event of an error isn't as good an idea as it may
first appear. For a Sieve syntax error that renders the entire Sieve
nonfunctional, maybe, but given that syntactic validity can and should be
checked before storing the Sieve, such errors should be quite rare.

The errors that slip through tend to be ones that are conditional in some way on the message being processed. In such cases disabling the script entirely prevents it from being applied to messages that don't trip the error condition. It's easy for this to turn into a cure that's much much worse than the disease.
In fact this behavior could be exploited as part of some sort of attack.

I agree.

- 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

You're seriously overstating this risk. See above.

Ok, I wouldn't call this a risk per se. It is more of a nuisance that should be prevented somehow. See above.

- extend ManageSieve with a means to get notified about runtime errors
and a means to retrieve (and possibly configure) runtime logs.

Unless the user's MUA does regular queries for this information, I don't think
this is a viable approach. It is quite common for the update interval for
Sieves to be measured in months or even years.

You are right, for the actual notification it would therefore not be suitable. It could however still be used to obtain detailed information about the error, e.g. after being notified about an error by some other means (also see postings by Kurt).



sieve mailing list