On Mon, 2006-11-27 at 01:59 -0800, Aaron Stone wrote:
On Sun, 2006-11-26 at 23:07 +0100, Kjetil Torgrim Homme wrote:
sounds to me like you want to use this to duplicate e-mail, for SarbOx
archival purposes or whatever. I don't think this is relevant for
Sieve. make the copy in your MTA so that the archival account is a
firstclass citizen as far as Sieve is concerned.
I'm sure some of my users have this in mind, and others have other
things in mind. If I provide multiscript functionality, that's one
feature for me to write and many purposes they can use it for.
I do agree that the specific case of keeping a second copy of mail is
probably better done by an MTA hook, if possible, but I don't see any
reason to prevent a Sieve script from being used for this purpose. Let's
not hang the whole discussion on this one use case, however -- given
that Ned and Tony have both said that their implementations have some
form of multiscript, I think we can assume that it is useful enough to
look into some more.
but Jutta's draft is very different, if a fileinto is taken, the next
script will not be processed (there is no longer an implicit or explicit
keep).
This is approximately how our implementation works. Again, the "most
specific" script that executes one or more explicit actions wins. So
if the system sieve says "fileinto spam" or "discard" but the user has
a sieve that says "keep", the keep wins. This makes various forms of
per-user, per-domain, and per-channel whitelisting and blacklisting possible.
the draft suggests that fileinto is disallowed to solve this
problem. also note that a discard can not be overruled by the user.
(I'm a bit mystified by Ned saying his system is similar to Jutta's)
This is one point where we differ. Again, system sieves need both an
overridable and a non-overrideable discard. We elected to implement a
nonstandard action "jettison" for this purpose.
from your first message again:
The special considerations I can think of are that the implicit keep
does not cross between the postmaster script and the user's script,
except in the case of a reject. That is, if the postmaster does a
fileinto, discard, keep, redirect, whatever, this affects only the
"postmaster's copy" of the message. A reject should trash the message
and cancel the user's delivery, however.
you seem to want to change the semantics of fileinto so that it does not
cancel implicit keep, unless when run as the last script. this sounds
very complex and confusing to me, and is the reason I suggest the
postmaster script works on a separate copy of the message.
That's only appropriate if you're using the script to implement something like
compliance archiving. I don't think sieve is necessarily an appropriate place
to implement this sort of thing because compliance archiving generally involves
saving pretty much everything, so what's the benefit of doing it in sieve?
Nevertheless, if you want to do it you will need a non-overrideable fileinto
that doesn't cancel implicit keep at other levels.
Message capture for law enforcement purposes is another interesting case. This
differs from compliance archiving in that everyone who works for, say, a bank
is going to be aware that everything they send is saved. But when that subpeona
arrives odds are it says that whoever is supposed to be monitored cannot be
made aware of the fact that monitoring is underway.
I know of no case law covering the case where monitoring was inadvertently
revealed to be taking place (pointers appreciated if anyone knows of a case),
but I wouldn't be at all surprised that lack of due diligence in this regard
might open you up to a contempt of court charge or even obstruction of
justice.
In any case, while we do provide a means of performing a special type of
archiving action in sieve, we prefer to use other means because sieve scripts
pretty much have to be visible to all sysadmins.
Ned