I would like to keep the envelope part in the spec, because one thought
is a server wide Sieve script that would see the multiple recipients.
I'll add a section in the security concerns about this use.
Ah, but therein lies the problem: The sieve specification quite clearly
states that envelope only operates on the single recipient address the
sieve is associated with.
Short of revising the base sieve specification, this isn't something
you're going to be able to do. And given the security issues I see no
chance of such a revision passing muster.
Ok, I'll remove any reference to server wide Sieve scripts.
What if I add the notation:
With the current Sieve specifications, this extension has limited uses
when
used with the envelope test. The test for envelope "to" will always
return
1 and the envelope "from" will always return either 0 or 1.
And in the security section:
An implementation MUST ensure that the test for envelope "to" only
reflects
the delivery to the current user.
The sieve spec seems to be geared largely at mailbox level filtering, and
sure for a mailbox level filter we should only allow access to 1 recipient,
but for domain or server level filtering perhaps there is application for
the envelope test having access to all the envelope recipients? There are
several such "tweaks" that you need to do when adapting Sieve to the domain
or server level. For example "fileinto" is really a "copy to directory" not
a "fileinto mail folder".
Is it really that harmful to put some comment in this spec to say:
A mailbox level implementation MUST ensure that the test for envelope "to"
only reflects the delivery to the current users, but a domain or server
level implementation MAY allow the envelope test to reflect the "to" or
"from" headers to the relevant domain or server.
?
Sieve isn't only useful at the mailbox level after all, it's great as a
server level spam filter too!
Nigel