Subject: Responses to comments on draft-ietf-sieve-editheader-00.txt

From: Philip Guenther <[email-masked]>
Date: Sun, 01 May 2005 21:35:04 -0700

Again, my apologies to the working group for the long delay in 
responding to the comments from the WGLC on this draft.  

I'm not going to list the trivial editorial changes here.

Matthew Elvey wrote:
>>   Tests and actions such as "exist" or "header" that examine
>
>The test is "exists", not "exist".  "Exists" and "header" are both
>tests, and actions don't examine.  Therefore, I suggest:
>       Tests such as "exists" or "header" that examine

Instead of restricting it to tests, I've added an action that
examines header fields:
   Tests and actions such as "exists", "header", or "vacation"
   [VACATION] that examine header fields MUST examine the current
   state of a header as modified by any actions that have taken
   place so far.

Mark E. Mallett wrote:
>>   use of [KEYWORDS] and "Syntax:" label for the definition of action
>
>I think labels are plural, so it ought to read "... labels for
>definitions of ..."

Not quite: the correct parse groups from "Syntax:" to the end of
the sentence.  Inserting a 'the' clears it up, I think:
   Conventions for notations are as in [SIEVE] section 1.1, including
   use of [KEYWORDS] and the "Syntax:" label for the definition of
   action and tagged arguments syntax.

(I.e., the conventions include "use of [KEYWORDS]" and "use of the
Syntax: label for...syntax")

>Just the obligatory comment about using "example.tld" even though "tld"
>isn't a real top level domain name today.

I've changed "foo.tld" to "foo.example.com":
        if not header :contains "X-Sieve-Filtered"
                ["<[email-masked]>", "<[email-masked]>"]
        {
                addheader "X-Sieve-Filtered" "<[email-masked]>";
                redirect "[email-masked]";
        }

>Should there be remarks about the potential damage that can be
>caused to the MIME structure of a message (e.g. by removing/adding
>MIME header fields)?

With regards to the effect this can have on the sieve processing
itself, see below.  Or were you suggesting a "this tool is sharp:
poking self in eye may harm depth preception" warning?

Nigel Swinson wrote:
>Is it worth making it explicit that if deleteheader can't find any
>matching headers then this isn't an error?

I've added the following as the last paragraph of section 4:
   It is not an error if no header fields match the conditions in
   the deleteheader action or if the :index argument is greater
   than the number of named header fields.

>I think we are saying that editheader does not cancel the implict
>keep (certainly this makes sense), but I don't think we've been
>very clear about it.  I liked the clarity of what was said in the
>vacation draft: "Vacation does not affect Sieve's implicit keep
>action."

I've added "The addheader action does not affect Sieve's implicit
keep." to section 3 and a similar statement for deleteheader to
section 4.

Cyrus Daboo wrote:
>4.5: replace ';' at end of paragraph with '.'. Add 'Example:' as    
>new line after paragraph.

Given the text following the example, I went with:

			      <...>  The counting happens
   before the <value-patterns> match, if any.  For example:

        deleteheader :index 2 :contains "Received" "via carrier-pigeon"

   deletes the second "Received:" header field if it contains
   <...>

Alexey Melnikov wrote:
>>   Actions that create messages in storage or in transport to
>>   MTAs MUST store and send messages with the current set of
>>   header fields.
>                        
>I am not sure I understand what is "in transport to MTAs", is this
>trying to say "in MTA's queue"?

It's trying to say that if you do something like forward the message,
the forwarded content reflects any changes.  Would it be clearer
if that sentence was simplified to

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

?

>>   MUST only file one message.  It is up to the implementation
>>   to pick which of the redundant "fileinto" or "keep" actions is
>>   executed, and which ones are ignored.
>
>I am not sure I like this, even though I understand the motivation.
>When Ned and Ken has discussed imapflags they agreed that the last
>keep wins (i.e. the current flags at the time of the last keep).
>Consistency is a good thing.  And the MUST at the beginning of
>section 5 seems to suggest the same.

I just reviewed the discussion on the from when it was changed to
this and the thought from at least a couple people at the time was
that leaving it open would ease implementation by making it agnostic
to the "evaluate as you go" vs "evaluate all at the end" choice.
Is there consensus to change this again?

(Previous to that, it called for *no* duplicate supression.)

Arnt Gulbrandsen wrote:
>Another minor point: If a message is rejected after being modified,
>which version of the message should be sent to the bounce address,
>the original message or the one with a modified header?

The one with the modified header.  This was covered by the "Actions
that create messages..." sentence in section 5, which I'm changing
to the "Actions that store or send the message..." sentence mentioned
above.

Now for the two ugly issues:

Ned Freed wrote:
>I think we need weasel words to the effect that changing the meaning 
>of the MIME structure with addheader may not produce results that
>actually affect subsequent body or other MIME-related tests.

(Also commented on by Arnt Gulbrandsen and William Leibzon)

Does the following, added after the first example in section 5,
give the correct dose of leeway?

   However, if the presence or value of a header field affects how
   the implementation parses or decodes other parts of the message,
   then for the purposes of that parsing or decoding the implementation
   MAY ignore some or all changes made to those header fields.  For
   example, in an implementation that supports the [BODY] extension,
   "body" tests may be unaffected by deleting or adding Content-Type
   or Content-Transfer-Encoding header fields.  This does not rescind
   the requirement that changes to those header fields affect direct
   tests; only the semantic side effects of changes to the fields
   may be ignored.

If not, where did I miss the turn?

Ned Freed wrote:
>>[Mark Mallett wrote:]
>> I really miss "replaceheader" and I think it's a huge mistake not to
>> include it.  "replaceheader" was the only way that one could rename a
>> header in place, which may have been one source of the objections to it,
>> but which I found to be the root of its value.  Perhaps a compromise
>> could be to include "replaceheader" as an optional additional capability
>> name in this document (the way that "fileinto" is included in the base
>> spec).
>
>FWIW, I miss it too.

I'm not enthralled by the idea of bringing replaceheader back into
the draft at this late date, especially given how the complexity
issues were never resolved.  I somehow suspect that the ensuing
discussion would be a cut-and-paste of the one that took place two
years ago.

Therefore, I am pushing back on these wistful thoughts.

Philip Guenther

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 02 May 2005 10:31:30 -0400

Hi Philip,

> Therefore, I am pushing back on these wistful thoughts.

In the interests of getting editheader finished soon, I agree with this 
approach, but I would like to hear from anyone who thinks replaceheader 
really must be present (of course we can add it as an extension at some 
later point if sufficient demand does arise later).

-- 
Cyrus Daboo

---

From: Philip Guenther <[email-masked]>
Date: Mon, 02 May 2005 10:58:52 -0700

Cyrus Daboo <[email-masked]> writes:
>Philip Guenther <[email-masked]> wrote:
...
>later point if sufficient demand does arise later).

For those who may have lost track of the discussion that led to
replaceheader being dropped, the relevant thread in the archives can be
found at:
    http://www.imc.org/ietf-mta-filters/mail-archive/msg01276.html

where it starts with Jutta's initial announcement of the editheader (and
copy and multiscript) drafts.

Philip Guenther

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 3 May 2005 14:51:19 +0200

Philip Guenther writes:
> that create messages..." sentence in section 5, which I'm changing to 
> the "Actions that store or send the message..." sentence mentioned 
> above.

Fine with me.

Please note specifically that addheader/refuse won't use the modified 
message, though. (Yes, I realize that for all known current 
implementations, addheader/refuse isn't possible in the first place.)

It could be (I don't know, nor really care) that you should mention that 
addheader/reject in that order could expose information unintended, so 
users should be careful where appropriate.

> Does the following, added after the first example in section 5, give 
> the correct dose of leeway?

Yes.

I'm not entirely happy that people can change message-id et al, but I 
don't think it's a big deal either. Some people always find means to 
shoot their lower extremities, and giving them one more doesn't really 
matter.

Arnt

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 3 May 2005 12:47:54 -0400

> later point if sufficient demand does arise later).

To me, it's "pick your evil."  One adds to the proliferation of
extensions, and separates things that really should be together.  The
other delays the standardization of 2/3 of those things.  Me, I'd vote
for the delay, especially considering that we can probably predict that
the "addheader/deleteheader" syntax is pretty well settled and it's not
much of a risk for people to start using that part of the extension.
e.g. I wonder how many implementations already include an "editheader"
extension that is being used despite not being standardized...

But I wouldn't be too upset about it going the other way, either.

mm

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 4 May 2005 13:24:26 +0200

Mark E. Mallett writes (about replaceheader)
> other delays the standardization of 2/3 of those things.

I think that view is too optimisic. I think the other _prevents_, etc.

If we repeat the 2003 discussion now, what will that change? AFAICT, 
nothing. I can't think of anything that has changed in the past two 
years, so we'll just spend a few months, arrive at the same conclusion 
as last time, and the draft will be x more months delayed.

Arnt

---

From: [email-masked]
Date: Wed, 04 May 2005 07:20:35 -0700 (PDT)

> as last time, and the draft will be x more months delayed.

Speaking as one of the people who wanted replaceheader back, I reluctantly
have to agree with this assessment. Let's move forward with what's there
now.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 May 2005 13:02:45 +0100

> implementations, addheader/refuse isn't possible in the first place.)

The text in -01 effectively says that "reject" should use the modified 
message. How is "refuse" different? If "refuse" uses an SMTP/LMTP 
response, than there is no message?

> It could be (I don't know, nor really care) that you should mention 
> that addheader/reject in that order could expose information 
> unintended, so users should be careful where appropriate.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 12 May 2005 14:05:14 +0200

> response, than there is no message?

Exactly.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 May 2005 13:19:24 +0100

>   current set of header fields.
Yes, that is much better. Thanks.

---

From: Matthew Elvey <[email-masked]>
Date: Thu, 12 May 2005 06:25:34 -0700

On 5/12/05 5:05 AM, Arnt Gulbrandsen sent forth electrons to convey:

>
> Alexey Melnikov writes:
>
>> The text in -01 effectively says that "reject" should use the 
>> modified message. How is "refuse" different? If "refuse" uses an 
>> SMTP/LMTP response, than there is no message?
>
>
> Exactly.
>
> Arnt
>
Or as I wrote on 5/9 in the latest revision of draft-ietf-sieve-refuse I 
sent Alexey:

> Any action that would modify the message body will necessarily have no 
> effect on the body of any message refused by "refuse" using the 550 
> SMTP response code.

Since it now defines reject too, perhaps draft-ietf-sieve-refuse is the 
wrong name... Let's go with draft-ietf-sieve-refuse-and-reject.