But Michael - think of it this way.
Many years ago there was only snail mail and there were rules and laws
in dealing with mail. Then came email which was totally different in
form - but totally identical in function.
In form snailmail was in an envelope and you weren't allowed to real
other people's mail and tear open the envelope. When email came to be -
there was no envelope - but the principle of private messages is still
somewhat established. (Thanks to EFF)
The issue is principle vs. method.
The principle of either implicit keep or explicit keep means to "keep"
the message. In most systems to keep the message means to deliver it to
the inbox. But - suppose the inbox was not the default destination for
mail? Then doesn'r keep really mean to deliver to the default destination?
In my case keep mean pass it on to a series of routers that does the
keep for me. In some cases there is no inbox to keep to. I process email
that is eventually delivered to other hosts for delivery (preprocess
spam filtering). So keep for those domains means to pass the message on
to the target host. So - if seive remains restrictive that it has to
deliver to a mailbox - it's totally useless in my environment.
What I'm suggesting is to preserve the spirit and principle of "keep"
but to allow the backent to be flexable as to the method of what keeping
means to that environment.
Michael Haardt wrote:
>On Mon, Oct 25, 2004 at 10:41:06AM +0100, Philip Hazel wrote:
>
>
>> implicit_keep = {false|true}
>>
>>That seems OK. Meaning "if nothing is done don't/do do a keep".
>>
>>
>
>Executing an implicit keep does not mean "nothing is done". It's
>like "there was no significant delivery".
>
>
>
>>Michael, how does that sound?
>>
>>
>
>To me, a keep is a keep is a keep, implicit or explicit. I don't like
>options to break RFC compliance, either, but features specific to Exim
>could be put into extensions specific to Exim. I suggested an extension
>"vnd.exim.route" in another mail. If a script requires that, it is
>obvious that it is not going to work anywhere else. If a script doesn't,
>a user can be sure what it does.
>
>Michael
>
>
>
