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

[[e-mail]]

> On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
> <[e-mail]> 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