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

Re: Action interaction - specifically discard+keep and discard+reject

2001-02-13 19:32:46
"Nigel Swinson" <Nigel(_at_)Swinson(_dot_)com> writes:

Suppose this is my script:

               if A { keep; }
          if B { discard; }

It is obvious what I've to do if either A or B is true, and if neither
A nor B is true, but what do I do when A AND B are true?

Do a keep (an explicit one).  Discard cancels the implicit keep and only
the implicit keep.

I think that I am meant to interpret it this way:  When I start
processing the script, the action on my list is "Implicit Keep".  When
I am told to "keep" then I cancel the "Implicit Keep", and replace it
with an explicit "keep".  When I am told to "discard" the message, I
would normally cancel the "Implicit Keep" but as I have already
canceled the "Implicit Keep", the "discard" has no effect here.

Yes.

Were the script to be the other way round, ie:

               discard;
          keep;

Then when I read the "discard" I cancel the "Implicit Keep", leaving me with
no actions on my list, and when I read the "keep", I place an explicit "keep"
on the list.

Yes.

Or am I meant to be producing a compile time/run time error?

So in terms of what we can conveniently tell the user in a rule based
GUI a discard says "Discard the message unless explicitly told to keep
it by another rule" and if they don't want other rules to mess them
about then they have to follow it with a "stop", and ensure that no
previous rule explicitly asked to keep this message.  But the discard
action isn't really a hard and fast "chuck away this message" unless
followed by a stop, and not preceeded by any keep commands?

Given a list of thems, they might be
        [] keep message in INBOX
        [] file message into mailbox [............]
        [] discard message (may be overridden by other actions)  

It can be done -- and in fact, it has.

Sticking to this precise definition of a "discard" to be cancelling the
implicit keep, am I right in saying that:

discard+reject = reject;

Yes.

reject+(keep or redirect or fileinto or reject) = error;

Implementation defined.  reject is required to send an MDN, and the
guarantee on deleted MDNs is very weak.  Section 2.10.4 discusses this,
and it is very weasely.

as reject presumably cancels the implicit keep 

A reject is defined to cancel the implicit keep, section 2.10.2.

too so the addition of discard
and reject isn't really an error as it just ends up with a reject.

2.10.2

   An implicit keep is performed if a message is not written to a
   mailbox, redirected to a new address, or explicitly thrown out.  That
   is, if a fileinto, a keep, a redirect, or a discard is performed, an
   implicit keep is not.


Presumably this list should include reject, or are we happy enough that it is
implied in the "Implementations SHOULD prohibit reject when used with other
actions" statement of section 2.10.4

This is the first bug in the RFC I've seen since it was published.
Given that was three weeks ago, I have to assume people are either
slipping or are just sick of reading it.  However, the next paragraph
makes the intent clear:

   Some actions may be defined to not cancel the implicit keep.  These
   actions may not directly affect the delivery of a message, and are
   used for their side effects.  None of the actions specified in this
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   document meet that criteria, but extension actions will.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^

That is, reject cancels the implicit keep.

Tim