ietf-822
[Top] [All Lists]

Re: Experiment #2 with multiple Reference headers (was References with multipl

2005-01-16 17:38:03

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
message
again.

which is a good example of why renaming header fields doesn't work very
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 instead add additional set of Resent-* header lines [aka headers] to the top of the message. The same document also explains that Resent-* headers have meaning as a group and must not be separated afterward. So situation that some other Resent-* header from previous addition gets mixed with newly added Resent- header is practically impossible (not unless there were no other trace headers
like received in between).

At the same time for majority of other headers (except Resent and Received)
adding additional header line with same name is not allowed. The common
practice has been to simply replace original header line with new one. But its really good for debugging of email routing problems to have seen what the value has been (for example I really would like to see original Sender header line value preserved somewhere for email messages that go through
email list).

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 in the Internet draft so if you like to provide some feedback about it, please go
ahead

Naturally, I'd like to see the draft before I comment on it.

Keith


<Prev in Thread] Current Thread [Next in Thread>