At 10:53 PM -0500 1/21/99, Lawrence Greenfield wrote:
This contradicts both of our interpretations, since I believe that
actions shouldn't override other actions, and you believe that it's ok
to reject and keep a message.
No, I think it is OK to both reject and redirect (forward) a message.
The message is not kept.
I believe that a sender receiving a rejection notice will believe that
their message was never read by a human. I'm not sure I like the idea
of fooling them.
Yes, this bothers me too. But is it any different from a case where
mail is sent to "luser(_at_)foo", which is actually an alias that expands
to "luser(_at_)bar, luser(_at_)gork", and mail sent to "luser(_at_)gork" bounces?
[forward; keep; v. just forward]
Interesting. To me (and in my implementation), the scripts are
identical semantically, as "keep" is performed by default unless a
"discard" or "reject" is done.
Implicit keeps are specified (in section 2.11.1) to be taken "if
evaluation of a script fails to result in one fileinto, keep, or
reject". I don't understand why this list doesn't include "discard".
Yes, it should include "discard".
I would argue that "forward" also belongs in the above list, since
that makes me think that the message usually won't be kept.
("redirect" has the same feeling to me.)
Did we separate "forward" and "redirect"? I'm sorry, I thought we
only changed the name of "forward" to "redirect" to avoid confusion.
Anyway, I disagree about forward/redirect being in the list, since to
me forward/redirect does not cause delivery or non-delivery. It is
merely an intermediate action, much as the "mark" extension in my
implementation (which adds a header).
> I think multiple fileinto's are a very useful thing---I think users
> will expect it, though I realize that this is hard (impossible?) for
> some systems. I think on those systems, multiple fileinto's should be
> handled the same way #1 is above.
I think this should be a compile error on systems that don't support
it. The question is how to spell it.
This is very hard (or impossible if you imagine an extension of some
tests) to detect at compile time. For instance:
if (size :over 50K) {
fileinto "big";
}
if (size :under 55K) {
fileinto "small";
}
That's my point exactly. We need to distinguish a single file-into
from a multiple file-into. Let's say we spell them "FileInto" and
"CopyInto". Then, if more than one "FileInto" is executed, only one
of them is effective (which one is an open point). If more than one
CopyInto is done, all are effective. If both a CopyInto and a
FileInto are done, both are effective.