[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sieve] Sieve include: interactions with MIME loops



> Posting this now.

Looks good to me.

				Ned

> On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed <ned.freed at mrochek.com> wrote:
> >> On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
> >> <alexey.melnikov at isode.com> wrote:
> >> > I am looking at the new text in draft-ietf-sieve-include-14.txt:
> >> >
> >> > 3.5.  Interaction with Other Extensions
> >> >
> >> >        When "include" is used with the Editheader extension [RFC5293], any
> >> >        changes made to headers in a script MUST be propagated both to and
> >> >        from included scripts.  By way of example, if a script deletes one
> >> >        header and add another, then includes a second script, the included
> >> >        script MUST NOT see the removed header, and MUST see the added
> >> >        header.  Likewise, if the included script adds or removes a header,
> >> >        upon returning to the including script, subsequent actions MUST see
> >> >        the added headers and MUST NOT see the removed headers.
> >> >
> >> >        When "include" is used with the MIME extension [RFC5703]
> >> >        "foreverypart" control structure, the included script MUST be
> >> >        presented with the current MIME part as though it were the entire
> >> >        message.  A script SHALL NOT have any special control over the
> >> >        control structure it was included from.  In the MIME example once
> >> >        again, a "stop" or "return" in an included script cannot directly
> >> >        terminate or continue flow of a "foreverypart" block.  In such a
> >> >        case, the included script should set a global variable that the
> >> >        including script can test.
> >> >
> >> > This makes me think that it is not clear what effect the "reject" action
> >> > would have if called in an included script within a "foreverypart" block.
> >> > What does it mean to "reject" a particular body part of a message?
> >
> >> I think it should immediately halt the script chain and reject the
> >> entire message.
> >
> > I don't agree; I think it should simply set reject as the script result
> > and continue. It's possible that some other action that's compatible with
> > reject (e.g., notify) would be done later. If you want it to halt you
> > can put stop after the reject.
> >
> >> I think stop does the same, except with the implicit
> >> keep as the default.
> >
> > Right, but stop should be the only thing that terminates execution.
> >
> >> Some text in an additional "interactions with other extensions"
> >> subsection should state this.
> >
> >> Oh man, here goes another rev.
> >
> > Good thing they're cheap.
> >
> >                                Ned
> _______________________________________________
> sieve mailing list
> sieve at ietf.org
> https://www.ietf.org/mailman/listinfo/sieve

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.