mike polniak <mikpolniak(_at_)adelphia(_dot_)net> writes:
Thanks. I did'nt find anything in the draft referring to "X-"
user-defined field names. What does this imply about using them, if anything?
Heh. The topic of the "X-" prefix generated over 130 messages on
the DRUMS list, according to the archive. After much argument, all
reference to the prefix was stripped from the document because there
was no concensus as to what could be usefully said.
My summary/interpretation of that discussion would be something like:
History has shown that our ability to predict whether a
new header is private and/or experimental, or worthy of
standardizing is poor to non-existent. At the same time, our
ability to design good headers appears to have no correlation
with that choice: "Return-Receipt-To:" was a disaster, while
"X-Face:" seems to be okay. Therefore, no useful meaning
can be placed on the presence of the "X-" prefix.
Programs should give meaning to standard headers, be they
de jure (official, probably documented in an RFC) or de facto
(unofficial, but in practice), but be robust in the face of
non-compliant input. For example, programs that consider
a message to have already been filtered because it contains a
"X-UIDL:" header field are _broken_: they should either strip
such fields on input to the larger "system" or tag the field such
that they can decide its validity with high assurance**.
** For example, when inserting such a header you could include in its
value the MD5 hash of the values of all the Received: header fields.
Then when reading a message, ignore any X-UIDL: header that doesn't
contain the correct hash.
If anyone is _really_ interested (or bored), I can forward them the
messages that made up the discussion on the mailing list.
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail