Re: [apps-discuss] apps-review team review for draft-melnikov-sieve-external-lists

[Barry Leiba <[e-mail]>]

Thanks for the review, Murray.

First, just making sure you reviewed the right document:
> Document: draft-melnikov-sieve-external-lists
It hasn't been that for a long time, and the correct current version
is draft-ietf-sieve-external-lists-07 :
http://tools.ietf.org/html/draft-ietf-sieve-external-lists

> Major Issues:
> 1. Altering list behaviour based on data available external to the Sieve processing
> code means alteration of such data presents a vector for attack.  The Security
> Considerations section should mention this.  It does mention some related issues
> (e.g., authentication) but not the one I have in mind, namely that the outcome of
> the Sieve script becomes dependent on external data not necessarily under direct
> control of the user.

Hm.  I'd have thought that to be sufficiently obvious as not to
require mention -- we *are* going out to an *external* list, after
all.  But I'm happy to put something in for that, sure.  How about
inserting the following paragraph after the one about "confidentiality
and authentication"?:
-------------
Having the processing and outcome of a Sieve script depend on the contents
of external data can allow someone with control of the external data to have
unusual, and perhaps unauthorized, control of the script -- and, consequently,
of the disposition of the user's email.  A user using such a list for
spam control,
for example, might find important mail being discarded because of tampering
with the list.  Someone using redirect to an external list could have her email
redirected to the wrong eyes because of such tampering.  Security and integrity
protection of external lists is as important as protection of the Sieve script
itself.
-------------

> 1. Since the document references the possibility of storing lists in external
> relational databases, I was surprised not to see a specific reference to how
> one might be used.  Is it the case that no URI schema exists yet for referring
> to, say, an SQL query?  If such does exist, an example of this would be good
> to include, but certainly not required (especially if such a schema has yet to
> be registered).

As I've said on the mailing lists about examples: I'm a fan of having
many examples, and I'll be happy to add more if someone would provide
me with specific text.  I'm loath to try to concoct more off the top
of my head at this point, and will rely on dependable submissions.

> Nits:
> 1. ":list" is sometimes quoted in the document and sometimes not.
> It should be consistent throughout.

It should; I've changed that in my working version.

Barry