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>
how does this error handling behaviour improve security?
This improves consistency of Sieve processing.
i fail to see why this is seen as a security issue
could anyone provide an example illustrating how an attacker could use
an implementation inconsistency in error handling to compromise a
sieve server?
Consistency makes security analysis simpler.
I suppose this can be moved out of the Security Considerations to
another section. How would you suggest to name such section?
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.
Besides, exactly the same wording was used in RFC 5490 and nobody in the
WG complained when it was last called.
could anyone provide an example illustrating how flaws in the original
Sieve specification's approach to error handling necessitate the
adoption of an alternative strategy in this new specification?
See above.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve