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.
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.
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).
I don't know what a "virtual user" is or why being one makes error handling
difficult, 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.
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)
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.
- 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.
- 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.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve