procmail
[Top] [All Lists]

Re: [META] Threading [Was: Bypass large files with filter]

2006-02-09 10:56:55
At 23:19 2006-02-08 -0700, Google Kreme wrote:

FWIW, Eudora includes thread references, but isn't itself a
threaded MUA:
message tracking within the app is by subject in a simple linear
mailbox view.

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 
defined).


citing RFC2822:

    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
    conversation.

    When creating a reply to a message, the "In-Reply-To:" and
    "References:" fields of the resultant message are constructed as
    follows:

    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:"
    field.

    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
    "References:" field.

[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:

      4.6.2.  IN-REPLY-TO

              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
         specification format.

      4.6.3.  REFERENCES

              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/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

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