In my previous message I said that I had other issues with the
document. Here they are:
Making :list a match type sorts out my issues with section 2.2, so that's fine.
But the same issues affect section 2.3. If the list can't be
enumerated, you can't redirect to it. Section 2.3 needs to make it
clear that whether an external list can do this or not depends upon
the list, and it needs to say what happens if it can't (ignore, or
throw runtime error seem to be the two sensible choices, and I think I
prefer the latter).
Section 2.4 says that the syntax of the list name is a URI, but it
doesn't talk about the semantics. Along with the change to 2.2,
section 2.4 needs to change to (1) note that some URI types make sense
and some don't (Alexey already has this on his to-do list, and (2)
explain that the URI has to resolve to something that can be used as a
list in the manner specified in 2.2 and 2.3... and talk a little about
what that means. Specifically, it has to be something that can be
given a string and can determine whether that string "is a member"...
and that it MAY also be something that can return its members as a
list or through an iterator.
Section 3, Security Considerations, needs some work, I think. First,
I don't like that there's some normative language there that doesn't
appear elsewhere. I prefer to have the normative parts of Security
Considerations be elsewhere in the document, in the parts that one
expects to be normative.
Second...
Protocols/APIs used to retrieve/verify external list membership MUST
provide at least the same level of confidentiality as protocols/APIs
used to retrieve Sieve scripts. For example, if Sieve scripts are
retrieved using LDAP secured with Transport Layer Security (TLS)
encryption, then the protocol used to retrieve external list
membership must use a comparable mechanism for providing connection
confidentiality. In particular, the protocol used to retrieve
external list membership must not be lacking encryption.
I don't think this is right. The connection between the Sieve
processor and the Sieve script store might be very different to the
connection it has with the external list. It's likely that it might
not be necessary to use TLS to retrieve Sieve scripts, but IS
necessary to use it to interact with the list, or vice-versa. I'd
rather decouple them, and just say that the Sieve processor MUST use
"appropriate security" to interact with the list, and that that may
mean using TLS, proper authentication, and whatnot -- but that it also
might not... say, in a closed system where the Sieve processor acting
on behalf of a user has direct access to the user's address book,
without fear of interception.
The normative text in the "mail bombs" consideration should move to
section 2.3, though I think it's still a good idea to mention the
issue here as well.
Barry