Subject: Interaction between "editheader" and "redirect"

From: Alexey Melnikov <[email-masked]>
Date: Wed, 07 Mar 2007 10:12:49 +0000

Folks,
Philip recently posted draft-ietf-sieve-editheader-08.txt. Below is the 
summary of changes done to address interaction between "editheader" and 
"redirect". I would like to quickly confirm that the changes are fine 
with everyone.

==============
Additional text in section 4 (Action deleteheader):

   If an script uses the deleteheader action to remove "Received"
   header fields and then performs a "redirect" action, the
   implementation SHOULD NOT send the outgoing message with fewer
   Received header fields than the original message.  If the
   implementation does not permit that for the involved script, it
   is implementation defined what Received header fields are present
   in such an outgoing message.  The above overrides the requirement
   on Received header fields in RFC-ietf-sieve-3028bis-12 section
   4.2.

The following paragraph in section 5 (Interaction with Other Sieve 
Extensions):

   All other actions that store or send the message MUST do so with
   the current set of header fields.

was replaced with:

   With the exception of the special handling of "redirect" and
   "Received" header fields described above, all other actions that
   store or send the message MUST do so with the current set of
   header fields.

Additional paragraph in section 7 (Security Considerations):

   While this specification overrides the requirement that redirected
   messages have more Received header fields than the message as
   received, doing so removes an important mechanisms for detecting
   loops and therefore should not be permitted by implementations
   without due consideration, such as requiring administrative
   action to enable it.

---

From: Ned Freed <[email-masked]>
Date: Wed, 07 Mar 2007 10:56:58 -0800 (PST)

>    on Received header fields in RFC-ietf-sieve-3028bis-12 section

I see three ways to implement this:

(1) Don't allow editheader actions on Received: fields, period.
(2) Silently ignore any deletions made to Recieved: fields when redirect
    is used.
(3) Add in enough dummy Received: field to keep the count from going down.

I'm going with option (2), but I have to question whether we really want to
allow (3). It sure sounds like a bad idea to me.

>    store or send the message MUST do so with the current set of

What about actions that result in a DSN or MDN that returns content? I don't
think it is a good idea to use the modified message in such cases.

I can interpret "send" as including or excluding such operations so I think
this could be a bit clearer.

>    without due consideration, such as requiring administrative

This looks fine to me.

				Ned

---

From: Aaron Stone <[email-masked]>
Date: Wed, 07 Mar 2007 11:39:37 -0800

On Wed, 2007-03-07 at 10:12 +0000, Alexey Melnikov wrote:

[snip]
>    store or send the message MUST do so with the current set of

I figure that 'current' is defined as 'the set of headers as modified by
the editheader commands at this point in the script' but I had to think
about it for a moment. Could we dumb it down a notch to make the meaning
of 'current' more explicit?

>    messages have more Received header fields than the message as
                        ^       ^ add double quotes to be consistent?
>    received, doing so removes an important mechanisms for detecting
                                                      ^ zap the 's'
>    without due consideration, such as requiring administrative
                              ^ end the sentence here?
>    action to enable it.

Aaron

---

From: Aaron Stone <[email-masked]>
Date: Wed, 07 Mar 2007 11:39:37 -0800

[snip]

                                                      ^ zap the 's'
                              ^ end the sentence here?

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 18 Mar 2007 20:21:38 +0000

> allow (3). It sure sounds like a bad idea to me.

I agree that we don't want to encourage (3).
Can we rephrase the text to say that if an implementation allows 
deletion of the Received headers, it MUST implement some other kind of 
loop control?

> think it is a good idea to use the modified message in such cases.

I agree that "reject" should be excluded from this rule as well.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 19 Mar 2007 04:41:34 -0400

Alexey Melnikov wrote:
>> I'm going with option (2), but I have to question whether we really
>>  want to allow (3). It sure sounds like a bad idea to me.
> 

I'd rather specify (1) but can live with (2).

Note, there is a 4th option, which I'll call (1a).

  (1a) Always silently ignore any deletions made to Received fields.

	Tony Hansen
	[email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Mar 2007 17:47:38 +0000

>  (1a) Always silently ignore any deletions made to Received fields.
I think you meant 2a, i.e. it is a modification of 2, rather than 1.

---

From: Aaron Stone <[email-masked]>
Date: Mon, 19 Mar 2007 11:30:08 -0700

> I think you meant 2a, i.e. it is a modification of 2, rather than 1.

+2. That is, +1 I like option 2a, and +1 Tony indeed meant 2a not 1a ;-)

Aaron

---

From: "Dilyan Palauzov" <[email-masked]>
Date: Mon, 19 Mar 2007 19:38:56 +0100

Hello,

> Can we rephrase the text to say that if an implementation allows deletion 
> of the Received headers, it MUST implement some other kind of  loop 
> control?

Suppose a message goes over hostA and hostB. hostA sends it to hostB, and 
hostB sends it to hostA. HostB deletes the Received: added by hostA, and 
hostA removes the headers added by hostB.

What kind of loop control can be here applied?

    Със здраве,
        Дилян