Subject: Limitation of editheader

From: Simon Josefsson <[email-masked]>
Date: Sat, 03 May 2003 20:33:32 +0200

The draft says:

,----
| 3. Action addheader
| 
|    Syntax:
|    	"addheader" <name: string> <value: string>
| 
|    The addheader action appends a header field to the existing
|    message header.
`----

It is problematic that the user cannot control where the header is
inserted.  I mentioned Received: earlier, but apparently that example
wasn't credible, so here is another, different, example.  There are
more headers that are order dependent, in case this isn't a credible
example either.

Consider the following usage:

set mydatestring ...;
set mymsgidstring ...;
if header :contains "Subject" "libidn" {
  addheader "Resent-From" "Simon Josefsson <[email-masked]>";
  addheader "Resent-Date" $mydatestring;
  addheader "Resent-Message-ID" $mymsgidstring;
  redirect "[email-masked]";
}

If the incoming message happens to contain Resent headers, this would
violate RFC 2822 which says the most recently introduced Resent-*
header block is the first one:

,----
| 3.6.6. Resent fields
|
|    Resent fields SHOULD be added to any message that is reintroduced by
|    a user into the transport system.  A separate set of resent fields
|    SHOULD be added each time this is done.  All of the resent fields
|    corresponding to a particular resending of the message SHOULD be
|    together.  Each new set of resent fields is prepended to the message;
|    that is, the most recent set of resent fields appear earlier in the
|    message.
`----

---

From: [email-masked]
Date: Sat, 03 May 2003 14:50:05 -0700 (PDT)

> |    The addheader action appends a header field to the existing

Prepending would be a better default.

>   redirect "[email-masked]";

I'm not sure I think this is legitimate usage, but in any case, I'd argue for
prepend since that's how headers are normally added.

				Ned

---

From: Jutta Degener <[email-masked]>
Date: Mon, 5 May 2003 10:48:28 -0700

On Sat, May 03, 2003 at 02:50:05PM -0700, [email-masked] wrote

> Prepending would be a better default.

The application I had in mind for "addheader" is very simple
flagging or priorization of messages by a user.  Just going by
"the important stuff first" aesthetics, I'd place such user
headers after the standard message headers, certainly not in
the middle of the Received: chronicle of delivery, even though
that would be temporally accurate.

But it's correct that both Resent-* and adding of Received:
headers don't work this way, and that it may be useful to
see where in the delivery process a header was inserted.

How about I change the default to insertion in front, and add
an optional :last that forces an append?

I've thought about adding more detailed positional parameters
to addheader, but couldn't come up with anything that wasn't
too complicated given the rarity of its use.

Jutta

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 05 May 2003 19:58:31 +0200

> Prepending would be a better default.

This sounds like a simple and reasonable solution; I'm for it.

I didn't think of this simple solution, so instead I imagined
something similar to deleteheader's :index and :last.  The addheader
:index would indicate the position the new header would be inserted,
at, and :last would start counting from the end instead.  This
solution appears more flexible, but I can't come up with an example
where prepending doesn't work.  I'm not convinced there aren't any,
though.

---

From: [email-masked]
Date: Sat, 10 May 2003 12:36:19 -0700 (PDT)

> an optional :last that forces an append?

Works for me.

> too complicated given the rarity of its use.

Exactly right IMO.

				Ned