--On Monday, September 07, 2009 10:41:49 PM -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Let step back a bit. Sieve scripts are frequently stored/retrieved in
LDAP, NFS and other similar types of storage. An implementation that
wants to invoke a Sieve script for a user would needs to retrieve it
first. This can fail, for example an attempt to read a Script from a
file can fail due to disk failure.
Very true, but the ability to handle this error at the time the scipt is
fetched does not translate into an ability to signal such a failure during
sieve execution. It certainly isn;t in our implementation, where
implementing
this form of error handling during script evaluation is going to be a
*major*
PITA.
What happens on such failure is implementation specific. It also happens
before the Sieve script is invoked at all, so arguably there is no
contradictions with the base Sieve document.
What you are suggesting is that that should be handled as a runtime
error (at this point it is too late for a compile time error, the script
is already installed). A runtime error means implicit keep. So you are
suggesting that a failure to retrieve a Sieve script should equate to
running a Sieve script containing "keep;". I don't think this is a good
suggestion.
I have to agree. I don't think this is a viable option and I'm afraid
that what the text currently suggests is the best we can do.
The only other alternative I can think of is for a failed test due to an
underlying list problem to set some sort of variable. But that forces
scripts
to handle the condition, which is very ugly.
Let's consider my suggestion in case of SMTP/LMTP delivery. LMTP server
is going to receive the email message and retrieve script for the user
associated with RCPT TO from an LDAP server. If there is a failure to
retrieve the script, then LMTP server can treat this as a temporary
error to deliver to the user. So it will respond with 4XX response and
the sender will retry email delivery later. At a later time the LDAP
server might become available again and the correct Sieve script will be
executed.
It may be straightforward when dealing with a simple LMTP server-based
implementation, but let's please not forget that such implementations
have the
serious issue that errors reported after message data transfer cannot in
general be reflected back as an SMTP error.
No, but one could certainly treat lists referenced in this way as a part of
the data needed to run the script, and fetch them up front, before the
script begins executing. Of course, that presumes that one can "fetch" the
list. The problem becomes much worse when the list is a query-only
service, because then you're going to need to talk to the service while
running the script, and _that_ could fail.
-- Jeff
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve