"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."
Use Case One: Public FOAF
how does banning access to public resources improve security?
Use Case Two: Web Services
how should an implementation judge whether a web service discovered
over UDDI (say) is more or less confidential than script storage in
LDAP (say)?
Complete agreement on all points. There are going to be all kinds of external
lists where the degree of confidentiality provided is an intrinsic
characteristic of the list itself and isn't under the control of the Sieve
implementation. There are also going to be cases where the Sieve
implementation is accessing the list through an intermediary and has no
way of determining what security, if any, is being employed in accessing
the list.
Specific examples of the latter would be a list provided by an LDAP proxy
server or a list provided by an LDAP server where the underlying attributes are
virtual and are resolved through some form of callout. Such setups are quite
common in practice.
The entire notion of there being a confidentiality requirement for
external lists independent of the list in question is completely silly.
Let's change this to say that both list content as well as the query stream
against the list MAY be confidential in nature and appopriate security
measures MUST be employed when they are.
Ned