ietf-mta-filters
[Top] [All Lists]

Re: Multiple actions in Sieve script.

1999-01-26 16:19:48
At 10:30 PM -0800 1/25/99, Ned Freed wrote:

> [M]y problem is more with people assuming that fileinto is even possible

FileInto is optional.  (It has to be, for example, for POP environments.)

Exactly. My point was that the implicit assumption behind all thie fileinto
discussion seems to be that it will be commonly if not universally available. I
don't think that's the case.

> I have a far bigger problem with the notion that somebody advanced of having
> multiple keeps deliver multiple copies of a message. This is unimplementable
> more often than not, as quite a few delivery schemes do duplicate address
> elimination, duplicate message elimination, or both. I cannot support such
> semantics, and I doubt I'm alone in this.

I don't think it makes sense (it isn't desirable) for multiple keeps
to be different than a single keep.

Exactly my point as well.

> As for the notion of removing keep as a default action, been there, done that.
> The first mail filtering language I ever did started out this way. Simply put,
> it was an unmitigated disaster. Default actions may be grotty, but they are an
> essential safety net that the language has to have.

> I do agree that the rule needs to be that the default is only taken when no
> other action of any sort, not just ones on a short list, has been.

So if a script only does a reply, is the message kept or discarded?
Neither is specified, so one has to be the default action.

I can argue this either way. In some cases a reply really is all you want.

All I can say is that in the past I've treated generation of replies as
an action that overrides the default, and nobody has complained. Quite
different from when there was no default action, I assure you.

What's wrong with saying that some actions affect delivery status,
and other actions don't?  Actions that affect delivery status are:
keep, discard, forward, reject.  Actions that don't are: reply, mark
(if this extension is supported).

The issue isn't so much with the present collection of actions (although
I suppose we could go back and forth quite a bit about whether or
not a reply implies reply and discard), but with future ones. Do we
really want to allow each action someone adds to say whether or not
it affects delivery status?

If so, I guess I can live with it. But I'm dubious as to whether or
not the complexity (remember, you're opposed to complexity ;-) is warranted.

                                Ned