gaw> Given the relatively unstructured nature of mail headers I don't
gaw> see why the support for multiple headers of the same name was
gaw> omitted from RFC 2822 either.
I believe the answer to this comes down more to social factors than to
technical ones. Back in the DRUMS days (for those who don't know,
DRUMS was the mailing list where discussions of rewrites of
RFC-821/822 into RFC-2821/2822 took place), if you wanted to start a
fairly vicious bar fight, you had only to ask this very question.
Although RFC-822 didn't have any text saying you couldn't have
multiple copies of a given destination header, the grammar is
reasonably clear on the point (at most one of each). It wasn't so
clear, of course, as to prevent some MUAs from making multiple TO/CC
headers on messages they created.
Since the multiple copies thing is, as they say, mostly harmless, the
recommended behavior described in RFC-2822 seems like the only choice
a reasonable implementor would make. Alas. There were people who
were fairly big movers and shakers on DRUMS who stated emphatically
that the obvious thing to do was to *ignore* the extra copies of the
destination headers. They thought that to do otherwise would not only
mis-serve their users, but could quite possibly end civilization as we
know it. Coincidentally, those folks were mostly purveyors of
widely-used MUAs that happened to implement it just they way they
thought it should be (ignoring the extra instances).
The end result is a slightly sad (in a geeky kind of way) compromise.
The clearly user-friendly behavior is described as obsolete and given
a "should" behavior. The user-unfriendly behavior is given the stamp
of legitimacy even though it can occasionally give a harmful sort of
surprise. In a thousand years, it probably won't matter.
--
bill@??? (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
