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.
Right.
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
deliveries.
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).
Regards,
Stephan.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve