Barry Leiba wrote:
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.
:list is not a match type in this case, again it is a black box.
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).
We should discuss this in Stockholm (and on the mailing list). I wasn't
thinking about being able to use the header test without being able to
reference the same list in redirect.
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,
Right.
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.
Ok.
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.
Agreed.
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.
Right.
I'd rather decouple them, and just say that the Sieve processor MUST use
"appropriate security" to interact with the list,
I think "appropriate security" is quite ambiguous.
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 intent was to cover this case.
I think an internal API which doesn't use a TCP protocol underneath (for
example) and can't be intercepted, then it is considered as secure.
But obviously your reading of this text doesn't agree with my intent, so
I will think about rewording.
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.
I am not sure this is needed. Similar text in the base Sieve spec is in
the Security Considerations section.