On Mon, 2007-04-23 at 18:46 +0000, Aaron Stone wrote:
On Mon, Apr 23, 2007, Nigel Swinson
<Nigel(_dot_)Swinson(_at_)rockliffe(_dot_)com> said:
FYI we support it this kind of way:
if header :is "From" "${Whitelist}" {...}
Where "Whitelist" is an externally configured list of email addresses.
Were
I to re-implement, then I'd put "Whitelist" in a namespace. I consider it
along the lines of accessing server configuration, for which we've already
discussed adding a namespace.
yes, definitely put it in a namespace, IMO it's needed to conform to
"variables".
intuitively, I don't like the use of ":is" here, but it may be down to
wording. if you said "externally configured search" instead of "list",
I don't think I would get the wrong association to Sieve lists.
there are some issues, what does "${whitelist} foo" mean? stuff like
that needs to be specified.
I would like to see a namespace or function space of some kind. A few
people pointed out that it might be good to specify an LDAP URI inside the
list description, so we're really talking about functions, imho.
I would like to stay away from functions if possible. how complex do we
need to be to handle the use cases people are thinking of? consider:
if address "From" "${addressbook.mailaddress}" ...
if header "From" "${addressbook.fullname}" ...
if header "From" "${addressbook.lastname}" ...
could be translated into an LDAP search for attributes "mail", "cn" or
"sn" respectively. OR and AND can be done at the Sieve level.
the hypothetical addressbook extension could also support
set "addressbook.baseuri" "ldap://ldap.uio.no/cn=mail,dc=uio,dc=no";;
but this quickly gets difficult to get interoperable since there is
little standardisation wrt which LDAP schema to use, and of course LDAP
isn't the only game in town.
HOWEVER: why use variables syntax -- this is similarily expressive:
if addressbook :fullname "From" ...
and we could even do
require "variables";
if address :domain :matches "From" "*" {
if addressbook :mailaddress :value :matches "*(_at_)${1}" ...
although it would probably better to make two tests, one for explicit
lookup value and one for lookup value fetched from headers.
yet another option is to use tagged arguments:
if envelope :addressbook :matches "From" "*"
if address :addressbook "From" :matches "*(_at_)example(_dot_)com" ...
it may be more natural to have only one mandatory argument and leave out
the "*", but I don't think we can change the syntax that way. instead
the above test could FIRST do a normal match, and THEN a list lookup.
(there is no way to do a search on surname or full name without
variables, however, since ADDRESS-PART doesn't include the tagged
arguments to extract those elements.)
I think I favour this approach as it is more general -- the tag can be
reused for "address", "header", "envelope" and "string". it's all a
hypothetical example, but I hope it illustrates some options. sorry for
rambling on :-)
The idea of IO bound operations from a sieve script such as LDAP/RBL
lookups
makes me twitchy about performance, but these concerns are of course
solvable using multiple threads/processes. I think it's the first time
we've suggested doing this kind of thing, so may be a knock to the
architecture of a few implementations and therefore make it difficult for
them to implement.
indeed. defered delivery is not uncommon in e-mail systems, but the
Sieve base document does not offer that as an error mode. is that
implicitly allowed? I think not, and wonder if we could/should add
wording which says something about temporary errors, e.g. that there
MUST be an upper time limit to defered delivery caused by problems
during execution before the default fallback action (ie., keep) is done
instead.
By using strict evaluation of variables, we set ourselves up for a
performance problem because we may be asking the interpreter to first
expand the full external list and then pass that into the test. Variables
says that implementations should be able to pass unexpanded material into
a test, but we still have keep the syntax of list expansions in mind so
that we don't force everyone into nasty interpreter hacks.
agreed. the idea is that variables without a namespace can always be
expanded. variables with a namespace may have magic associated with
them so whether to expand them before calling the action or test should
be determined per namespace.
--
Kjetil T.