Subject: Re: Working Group Last Call: draft-ietf-sieve-editheader-00.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 05 Apr 2005 10:10:45 +0100

Cyrus Daboo wrote:

> I would like to draw your attention to the following draft:
>
> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-editheader-00.txt>

A little bit late comments:

 >5. Interaction with Other Sieve Extensions
 >
 >   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"?

 >   For the purpose of weeding out duplicates, a message modified
 >   by addheader or deleteheader MUST be considered the same as
 >   the original message.

Hmm, even if the scripts replaces the Message-Id header ;-)?

 >  For example, in an implementation that
 >   obeys the constraint in [SIEVE] section 2.10.3 and does not deliver
 >   the same message to a folder more than once, the following
 >   code fragment
 >
 >       keep;
 >    addheader "X-Flavor" "vanilla";
 >    keep;
 >
 >   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.

Alexey

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 5 Apr 2005 13:07:11 +0200

> Hmm, even if the scripts replaces the Message-Id header ;-)?

It seems to me that banning removal/addition of certain fields 
simplifies life a lot without removing significant benefit: Message-ID, 
Content-Type, Content-Transfer-Encoding and MIME-Version.

Modifying those four fields adds so many corner cases to the 
implementations. Do we have to go there? Is it perhaps better to just 
say "editheader operations MUST NOT modify those four fields"?

(Solving a difficult problem gives a certain satisfaction. But avoiding 
it can be good, too.)

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 5 Apr 2005 13:15:40 +0200

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?

Sorry I didn't notice that until now.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 5 Apr 2005 14:16:31 +0200

william(at)elan.net writes:
> On Tue, 5 Apr 2005, Arnt Gulbrandsen wrote:
>> Is it perhaps better to just say "editheader operations MUST NOT 
>> modify those four fields"?
>
> This is definetely better. I've not seen those header fields ever 
> being modified by intermediate MTAs (forwarders, mail lists, etc) nor 
> is there any reason why they should by MDAs or their agents. The only 
> thing is that Content-Transfer-Encoding may in theory be subject to 
> changes if MDA wants to decode BASE64 into something more readable 
> for MUAs (in theory it should not try though).

That's not relevant to the editheader extension.

Arnt

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 5 Apr 2005 05:09:06 -0700 (PDT)

On Tue, 5 Apr 2005, Arnt Gulbrandsen wrote:

> It seems to me that banning removal/addition of certain fields simplifies 
> life a lot without removing significant benefit: Message-ID, Content-Type, 
> Content-Transfer-Encoding and MIME-Version.
>
> Modifying those four fields adds so many corner cases to the implementations. 
> Do we have to go there? Is it perhaps better to just say "editheader 
> operations MUST NOT modify those four fields"?

This is definetely better. I've not seen those header fields ever being 
modified by intermediate MTAs (forwarders, mail lists, etc) nor is there 
any reason why they should by MDAs or their agents. The only thing is that
Content-Transfer-Encoding may in theory be subject to changes if MDA wants
to decode BASE64 into something more readable for MUAs (in theory it 
should not try though).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 05 Apr 2005 17:16:23 +0200

> say "editheader operations MUST NOT modify those four fields"?

sounds like a good idea.  here's one use case though:

I've seen quite a bit of e-mail from Russian users who use Hotmail with
KOI8-R, but Hotmail tags it as ISO 8859-1.  it would be useful to be
able to correct the Content-type header here, both to get correct
BODY-matching and to let the MUA view the e-mail properly.

I can't think of use cases for the other headers.
-- 
Kjetil T.

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 5 Apr 2005 10:30:11 -0700 (PDT)

On Tue, 5 Apr 2005, Arnt Gulbrandsen wrote:

>>> Is it perhaps better to just say "editheader operations MUST NOT modify 
>>> those four fields"?
>> 
>> to decode BASE64 into something more readable for MUAs (in theory it should 
>> not try though).
>

The point is that if MDAs do it, so could SIEVE system to make it easier 
for other rules, but it really should not care about it and let other 
rules work with data that is in BASE64 same as if was clear text.
And I'm not entirely sure if that is actually mentioned or not.

-- 
William Leibzon
Elan Networks
[email-masked]