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.
...
So I would like to correct your statement. There is no need whatsoever to be
able to enumerate list membership in Sieve in order to redirect.
The only requirement is that whoever does mailing list expansion needs to be
able to do that. Such entity doesn't have to be the Sieve engine.
Two things:
1. When I say that the list must be enumerable, I don't necessarily
mean "by the Sieve engine." It's possible for the list not to be
enumerable at all, even by the list handler. Examples are where the
list stores hashes of email addresses (to preserve privacy, perhaps)
and where the list stores mailbox patterns (all members of department
Z have email addresses that start with "dz", so the list of department
Z members is querieable ("Is X a member?"), but not enumerable).
2. Ah, so you're suggesting that the Sieve engine, which knows how to
do a redirect, should pass this on to the list handler, which now also
has to know how to do a redirect. I'm not sure that's a good idea,
but I could perhaps be convinced. I'm curious about what Ned thinks
here.
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.
There's also the case where the list is not a list of email addresses.
In that case, it can certainly be used for section 2.2, but not for
2.3. 2.3 still has to say what to do. Repeating, I think it's a
"SHOULD [or maybe MUST] cause a runtime error" if the list can't be
used for redirect because of the type of list it is (which includes
the discussion above).
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.
I don't think it's ambiguous, but, not, it's not well specified. I
expected to put more words in to be clearer, but the point is that
it's ultimately the responsibility of the implementation to know
what's appropriate. There's a difference between making an LDAP
request in a closed LAN that's only used for trusted servers (neither
encryption nor authentication may be needed), a firewalled LAN for a
particular company (it might be OK to skip encryption, depending upon
policy), or the open Internet (encryption and authentication probably
required), and whether the list being accessed is private or public
(no encryption or authentication needed for public data, even on the
Internet).
We can't dictate any of that in the spec... we can only give examples
and advice, and leave the final choice of what's "appropriate" to the
implementation.
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.
OK. I don't have a very strong opinion here. I think it's harmless
and possible helpful to put the normative bits earlier in the
document. But it's OK with me if consensus is that it doesn't matter.
Barry