[Top] [All Lists]

Re: [sieve] [draft-melnikov-sieve-external-lists] 3. Security Considerations, Paragraph 2

2009-08-27 18:25:15
Robert Burrell Donkin wrote:

  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.

how does this error handling behaviour improve security?
This improves consistency of Sieve processing.
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?

sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [sieve] [draft-melnikov-sieve-external-lists] 3. Security Considerations, Paragraph 2, Alexey Melnikov <=