At 7:03 PM -0500 1/25/99, Tim Showalter wrote:
I understand your position, but I don't like it. I don't mean to make
this sound like a flame, but I'm really not happy about arbitrary limits
on numbers of actions, especially ones like FileInto which can be
considered to be harmless. I don't know how common this problem is
going to be, but I really thought it was nonexistant until you brought
it up.
I thought the goal of Sieve was a language that was powerful enough
to be useful, and simple enough to be safe and easily implemented.
I have one working Sieve implementation, and another in development
(same core code) that use a plug-in API model. The Sieve agent is
called during (but before) final delivery. It is passed the incoming
message, including envelope. Sieve gets to reject the message or
alter the mailbox into which it will be filed. (It can also forward
or reply, but those actions do not effect message disposition as far
as the plug-in API is concerned.)
I doubt this environment is unique.
If we define a FileInto action which takes one mailbox name as a
parameter and causes the message to be delivered into that mailbox
instead of the default, we have something that can be implemented
very widely.
If we instead define a FileInto which takes multiple mailboxes, or
has any other semantics, we gain some power but reduce either
interoperability or deployability.
How important is the ability to simultaneously deliver into multiple
mailboxes? If we don't absolutely have to have it, I say we leave it
for an extension. If it is so vital as to justify delay and reduced
interoperability or deployability, please explain why, because I just
don't see it.
I guess that if I write my scripts well I will typically file on
Return-Path, so it can be dealt with.
I don't understand this comment.
I use Sieve to process all my incoming mail at work. The Sieve
script is close to 300 lines, and files mostly based on envelope
return-path.
How does this affect the need for multiple FileInto?