On Sun, 16 Jan 2005, Keith Moore wrote:
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). So some software instead of removing the header line that it
is about to be replaced, duplicates it into corresponding Original- (some
rename and leave in same place inside email headers structure, this is
less good) and then adds new header line with same name. So in practice
Original- header lines are more like email trace header fields (and
similarly multiple of same named ones can be in the message) and have same
purpose to help track changes to email message, they should not be viewed
as replacement for real headers or used directly by MUA.
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 (and note that I already know of number of different programs adding
these headers without any documentation and draft will try to keep it
primarily as documentation of current practice and explain what these are).
Accidentally I can't find any good way to register with IANA a group of headers
like Original- (as common prefix) as RFC3864 specifies only how to do it for
one particular header field. Please suggest what to do about it.
(actually, resent doesn't work very well. but it's rarely a problem as
long as it is only used for its intended purpose. unfortunately people
keep trying to redefine the meaning of resent-* and other fields, most
recently to accommodate various shortsighted anti-spam schemes)
I certainly agree with you that Microsoft proposed SenderID ho they want to
use Resent- headers is incorrect and against existing standards (RFC2821)
and in general their proposal is bad and will hardly do anything to stop
spam flow of spam or phishing.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/