Limitation of editheader

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 <simon(_at_)josefsson(_dot_)org>";
  addheader "Resent-Date" $mydatestring;
  addheader "Resent-Message-ID" $mymsgidstring;
  redirect "bug-libidn(_at_)gnu(_dot_)org";
}

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.
`----