[Top] [All Lists]

Message-ID problems

1991-07-10 04:39:06
Henry Spencer writes:
| 1. How many people have noticed that it appears to be perfectly legal
| for an RFC822 message to contain more than one Message-ID header?

I have noticed that zero, one, or more Message-ID headers are allowed.
I don't like that.

| 2. What fraction of software that is cognizant of message IDs will
| actually deal with this correctly (at a minimum, without dumping
| core!)?

Mine removes duplicate headers where the field value can't be a list.
E.g. multiple From, To, Cc are joined into one with all the values.

| 3. Is this considered desirable, or is it worth fixing in the 822
| revision?

I would like to see that exactly one Message-ID header be attached to
every single message at the source of the message, preferably by the
user agent.  I would also like to see any site which removes or alters
Message-ID's be shut down for repairs.  Message-ID should be mandatory,
along with From.  And they should be sacrosanct, immutable, inviolable.
The In-Reply-To field MUST contain a message id in angle brackets (<>)
and nothing else must occur inside <>.  (Whatever is outside <> should
be ignored.)  The References field should be applied to mail, as well,
to track threads and discussions.

I have noticed that systems who don't add (or delete! *fume*)
Message-IDs make systems en route add their own Message-ID, resulting
in hundreds of Message-IDs per message from, e.g., BITNET LISTSERVers.
Mailers that use it for message-thread identification lose, and
complain about missing parent articles.  (It's also nearly impossible
to delete quoted material and introduce hypertext-like links to the
original article, something I've yearned for and played with for a long

PS: Hi, all.  I'm back.  4 million unread articles in ietf-822 and
ietf-smtp, here I come.  Also, please note new domain name.

Erik Naggum             Professional Programmer            +47-2-836-863
Naggum Software             Electronic Text             
0118 OSLO, NORWAY       Computer Communications        

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