"Jason R. Mastaler" <[EMAIL PROTECTED]> writes:

> Tim Legant <[EMAIL PROTECTED]> writes:
> 
> > to [EMAIL PROTECTED] deliver=~/Mailbox
> > to [EMAIL PROTECTED] deliver=| pager-program
> 
> This isn't very intuitive to me and doesn't really follow the "first
> match wins" methodology we are used to.

I agree.  Docs would have to change and it might not be possible to
keep old filters working right.  Not good.  Also, there is a problem
of conflicting actions ([EMAIL PROTECTED] is dropped, but later,
*@example.com is accepted).  These problems are why I haven't tackled
the general issue earlier.

> Assuming this were possible, I think something like this would look
> better to me:
> 
> # bounce the message, but also save it
> to [EMAIL PROTECTED] bounce, deliver=~/Mailbox.bounces
> 
> # bounce the message, but also save it and pipe it to my pager
> to [EMAIL PROTECTED] bounce, deliver=~/Mailbox.bounces, |pager-program
> 
> So, the comma can be used to indicate multiple actions and/or multiple
> delivery destinations.

We could run into weird problems, like this (same as your second
example, but the user used a different order):

# bounce the message, but also save it and pipe it to my pager
to [EMAIL PROTECTED] deliver=~/Mailbox.bounces, |pager-program, bounce

This appears that we should deliver to 'bounce', whatever and wherever
that is.  If we go this route, we would have to insist that the
'deliver' action be the last on the line.

> ... At first glance, multiple rule matches doesn't seem as useful to
> be as having multiple delivery destinations, but who knows what the
> future holds?

I lean this way, too.  And doing it would introduce the bizarre
ordering rule above.  People like consistency, not strange exceptions,
so I'm inclined to just go for the multiple destination support.

> I'd prefer to not have to quote unless one is actually using a comma
> in a filename. The vast majority of users will not being doing this,
> so let's not cater to the oddball.

Yes, I didn't mean quote all the time, but only when it's ambiguous.
The parser has to support it all the time, though, simply because it
doesn't know whether it's necessary or not.


Tim
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers

Reply via email to