[Top] [All Lists]

Re: Interaction between "editheader" and "redirect"

2007-03-19 01:37:54

Ned Freed wrote:

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

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.

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?

The following paragraph in section 5 (Interaction with Other Sieve

   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.

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 agree that "reject" should be excluded from this rule as well.

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