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.
But while I don't like the current approach much, I have no better replacement
to suggest.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve