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

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

2012-01-31 11:42:03
Posting this now.

On Mon, Jan 23, 2012 at 5:00 PM, Ned Freed 
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
On Sat, Jan 21, 2012 at 5:31 AM, Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)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(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve