I'm afraid we've had that for some time. For example, if I recall
correctly, Pine renames "resent-" header lines if you resend the
which is a good example of why renaming header fields doesn't work
well. we don't need to rename received fields, why do we need to
rename other fields?
RFC2821 is quite clear that software should not be doing it but should
add additional set of Resent-* header lines [aka headers] to the top
message. The same document also explains that Resent-* headers have
as a group and must not be separated afterward. So situation that some
Resent-* header from previous addition gets mixed with newly added
header is practically impossible (not unless there were no other trace
like received in between).
At the same time for majority of other headers (except Resent and
adding additional header line with same name is not allowed. The common
practice has been to simply replace original header line with new one.
its really good for debugging of email routing problems to have seen
the value has been (for example I really would like to see original
header line value preserved somewhere for email messages that go
Lists that set Sender are broken anyway, because (as you point out)
this obscures who originally sent the message. Of course, there are
exceptions - such as digests and anonymous lists - but they're rare.
In general, if software thinks it needs to rename a field that's
already there, there's usually something fundamentally wrong with the
_intent_ of that software. The primary purpose of submission agents,
MTAs, lists, and recipient MUAs is to _preserve_ the original message,
not to alter it.
Again, there are exceptions that justify some lack of transparency,
such as virus filters. But those should be acting on entire messages
or entire body parts - they shouldn't be messing with fields of
messages and body parts that they deliver intact.
Now as has been mentioned, I plan to document these Original- headers
Internet draft so if you like to provide some feedback about it,
Naturally, I'd like to see the draft before I comment on it.