Robert Burrell Donkin wrote:
On Sun, Sep 6, 2009 at 7:17 PM, Alexey
Melnikov<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Robert Burrell Donkin wrote:
On Thu, Aug 27, 2009 at 11:13 PM, Alexey
Melnikov<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Robert Burrell Donkin wrote:
<blockquote
cite='http://www.ietf.org/id/draft-ietf-sieve-external-lists-00.txt'>
A failure to retrieve data due to the server storing the external
list membership being down or otherwise inaccessible may alter the
result of Sieve processing. So implementations SHOULD treat a
temporary failure to retrieve or verify external list membership in
the same manner as a temporary failure to retrieve a Sieve script.
For example, if the Sieve script is stored in the Lightweight
Directory Access Protocol (LDAP) and the script can't be retrieved
when a message is processed, then the agent performing Sieve
processing can, for example, assume that the script doesn't exist or
delay message delivery until the script can be retrieved
successfully. External list memberships should be treated as if they
are a part of the script itself, so a temporary failure to retrieve
them should be handled in the same way as a temporary failure to
retrieve the Sieve script itself.
</blockquote>
[...]
If there is WG consensus to change this, then I would argue we would need
a
mechanism to detect membership verification failures using a new test (or
a modifier to existing one).
what are the advantages of this new error handling language to that
already established in RFC 5228?
i fail to see the security reasoning justifying deviation from the
error handling laid down in the basic Sieve langauge specification
I actually disagree. The proposed error handling makes it consistent with
the base specification. The idea behind the text is as follows: if there is
a Sieve script that contains the list of all members in the script itself,
the Sieve script processing shouldn't change when the script is changed to
use external lists and all previously inlined members moved to an external
list.
the current solution does not achieve this aim
the base specification describes two clearly error handling
strategies. when a internal list is incorrect then either a compile
time or runtime error should be raised by the engine (as described in
the specification). the proposal adds a novel (and quite ill defined)
error type and therefore introduces a change in behaviour for some use
cases when a list is move from internal to external.
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.
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.
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.
Besides, exactly the same wording was used in RFC 5490 and nobody in the WG
complained when it was last called.
IMHO a mistake in one specification should not be used to justify it's
propogation
True, if we can come to consensus that this was indeed a mistake.
perhaps better reviewing would have spotted this inconsitency with the
original sieve language specification
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve