Alexey Melnikov | 21 Jan 2012 14:31
Favicon

Sieve include: interactions with MIME loops

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?
(Continue reading)

Aaron Stone | 24 Jan 2012 01:25
Gravatar

Re: Sieve include: interactions with MIME loops

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
(Continue reading)

NED+mta-filters | 24 Jan 2012 02:00

Re: Sieve include: interactions with MIME loops

> 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
(Continue reading)

Aaron Stone | 31 Jan 2012 18:41
Gravatar

Re: Sieve include: interactions with MIME loops

Posting this now.

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.
(Continue reading)

Barry Leiba | 31 Jan 2012 22:07
Picon
Favicon
Gravatar

Re: Sieve include: interactions with MIME loops

> Posting this now.

That looks like what we want (the -15 version).  Now just put out a
-16 to fix the "foreverpart" typo you just introduced, and we'll move
it along.

>>> Oh man, here goes another rev.
>>
>> Good thing they're cheap.

Indeed.

Barry, shepherding
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve

Aaron Stone | 31 Jan 2012 22:59
Gravatar

Re: Sieve include: interactions with MIME loops

Oof :(  Thanks for reviewing the changes!

On Tue, Jan 31, 2012 at 1:07 PM, Barry Leiba <barryleiba <at> computer.org> wrote:
>> Posting this now.
>
> That looks like what we want (the -15 version).  Now just put out a
> -16 to fix the "foreverpart" typo you just introduced, and we'll move
> it along.
>
>>>> Oh man, here goes another rev.
>>>
>>> Good thing they're cheap.
>
> Indeed.
>
> Barry, shepherding
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve

Barry Leiba | 6 Mar 2012 03:47
Picon
Favicon
Gravatar

Re: Sieve include: interactions with MIME loops

PING!

> That looks like what we want (the -15 version).  Now just put out a
> -16 to fix the "foreverpart" typo you just introduced, and we'll move
> it along.

Aaron: please post a -16 version with the typo fixed, and I will tell
Pete to go ahead with this.

Barry, shepherd
_______________________________________________
sieve mailing list
sieve <at> ietf.org
https://www.ietf.org/mailman/listinfo/sieve

NED+mta-filters | 1 Feb 2012 04:54

Re: 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
(Continue reading)


Gmane