At 23:19 2006-02-08 -0700, Google Kreme wrote:
FWIW, Eudora includes thread references, but isn't itself a
message tracking within the app is by subject in a simple linear
I think Eudora threads using the Subject and the References headers,
Eudora doesn't thread at all. It presents a flat mailbox list. I don't
run the latest-greatest version of Eudora (I tired of paying money over and
over again, when the tool I have already does what I need it to), but I've
installed it on enough machines to say there's nothing significantly
different in the thread handling in v7.
I'm running 5.1.1, the copyright of which predates RFC2822. I respectfully
suggest that the problem here is that the software exhibiting issues with
reconstitution of threads makes no allowances for pre-RFC2822 formatted
messages (in which the content of these headers was a lot more loosely
The "In-Reply-To:" and "References:" fields are used when creating a
reply to a message. They hold the message identifier of the original
message and the message identifiers of other messages (for example,
in the case of a reply to a message which was itself a reply). The
"In-Reply-To:" field may be used to identify the message (or
messages) to which the new message is a reply, while the
"References:" field may be used to identify a "thread" of
When creating a reply to a message, the "In-Reply-To:" and
"References:" fields of the resultant message are constructed as
The "In-Reply-To:" field will contain the contents of the "Message-
ID:" field of the message to which this one is a reply (the "parent
message"). If there is more than one parent message, then the "In-
Reply-To:" field will contain the contents of all of the parents'
"Message-ID:" fields. If there is no "Message-ID:" field in any of
the parent messages, then the new message will have no "In-Reply-To:"
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). If the parent message does not contain
a "References:" field but does have an "In-Reply-To:" field
containing a single message identifier, then the "References:" field
will contain the contents of the parent's "In-Reply-To:" field
followed by the contents of the parent's "Message-ID:" field (if
any). If the parent has none of the "References:", "In-Reply-To:",
or "Message-ID:" fields, then the new message will have no
[okay, so this paragraph above indicates that per RFC2822, the In-Reply-To:
messageid should be part of the collection of IDs in References]
Note: Some implementations parse the "References:" field to display
the "thread of the discussion". These implementations assume that
each new message is a reply to a single parent and hence that they
can walk backwards through the "References:" field to find the parent
of each message listed there. Therefore, trying to form a
"References:" field for a reply that has multiple parents is
discouraged and how to do so is not defined in this document.
Compare to RFC822:
The contents of this field identify previous correspon-
dence which this message answers. Note that if message iden-
tifiers are used in this field, they must use the msg-id
The contents of this field identify other correspondence
which this message references. Note that if message identif-
iers are used, they must use the msg-id specification format.
Yea, that's the sum total of the spec fof "References:" in RFC822, aside
from the syntax rules, which doesn't specify WHAT the content is, merely
what the format is. Note that References is identified as "other
correspondence", which could be interpreted to be in addition to the
message already identified in the In-Reply-To: header, which is likely the
case with Eudora.
It is putting Sean's posts first because it thinks Sean's posts are
earlier based on him being way over in the Pacific time zone and
Eudora has been piss-poor about accounting for time zones for going
on a decade now.
Er, how is the datestamp on any of my messages any different from yours,
with the exception that the timezone offset is -0800 instead of -0700 for you?
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
procmail mailing list Procmail homepage: http://www.procmail.org/