2 Jul
2012
2 Jul
'12
11:18 a.m.
Mouse <mouse at rodents-montreal.org> wrote:
Other sources of commas in References: are software
that copies
existing References: blindly, adding message-IDs to one end or the
other, thus perpetuating mistakes but at least not making them worse.
Indeed, the example quoted above must have come from such a thing,
since it is lacking the comma between the third and fourth message-IDs.
This is then probably "my fault". My MUA just copied the References: which
where already present and didn't "fixed" them. But - there is no paragraph
in the RFC about fixing wrong headers ;)
from the RFC 5322:
The "References:" field will contain the contents of the parent's
"References:" field (if any) followed by the contents of the parent's
"Message-ID:" field (if any).
This is exactly what my MUA did - there is nothing about "...will contain
the _fixed_ contents of the..." ;)
And if your MUA is not able to handle the References header with comma
and/or without - you are not able to read old emails written until RFC 5322
came out and thus having "," in there References header?
If this would be my MUA, I would start complaining to it as it should have
some sort of fallback plan in case a message arrives which is compatible to
older RFCs. You probably can't make sure that all users in the world will
immediatly switch to MUAs always compatible to the latest RFCs - you'll
always have MUAs around which are not 100% compatible to the latest but
to an older version of RFC (or to no RFC at all). Probably there should
be a "Compatible-with:" header..........
Expecting every MUA to be compatible only to the latest RFC is a little
bit naive - eh? Instead of tilting at windmills, save your time ;)