HiJacking Threads Was: hostapd for Fedora 10

[Patrick O'Callaghan]

On Tue, Jan 6, 2009 at 7:17 PM, Ed Greshko <Ed.Greshko at greshko.com> wrote:
> Patrick O'Callaghan wrote:
>>
>> Then I'm somewhat at a loss to understand what you mean by threading.
>> The linking of replies to the messages being replied to joins the
>> entire set together into a thread. The presentation of the thread as a
>> visual hierarchy or whatever is a matter for the MUA.
>>
> Take 4 messages, each written by a different person....
>
> W - Original Message
> X  - In-Reply-To W
> Y  - In-Reply-To X
> Z  -  In-Reply-To Y
>
> If you rely solely on the "In-Reply-To" header there is no practical
> method to link Z to W.

Except by linking Z to Y to X to W, which amazingly is what mail
clients actually do!

This would be especially true in the event where
> either X or Y did not arrive or does not exist on the message store of
> the local MUA.  Once has always to take into account these types of
> circumstances.

Naturally. One quickly learns that when the Internet Gods say that
mail is unreliable, they really mean it, and any software which
doesn't take this into account will crash and burn. To return to the
point: when delayed messages arrive, they are appropriately inserted
in the thread the next time the MUA refreshes its folder view, and of
course if they don't, they aren't. An additional header called
References might help in some cases, but not if the original message
never arrived, so we're back where we started. The MUA does what it
can with partial information (and it almost never knows if what it has
is partial or complete).

>>> FWIW, I've found that RFC 2822 has a better discussion of the use of
>>> "in-reply-to" and "references" headers and their intended usage.
>>>
>>
>> I quoted RFC822 because you said you weren't aware of RFCs which
>> specify threading, and 822 is the original standard reference for
>> email (at least in the form that's still in use).
>>
> But...  RFC822 *does not* talk about threading.  You are implying that.

As I already said, I know it doesn't talk about threading, but it
implies certain things about it (otherwise, what is the point of the
In-Reply-To header?). The RFC authors are usually very careful not to
overspecify things, especially when there isn't enough real-world
experience, so it's no surprise that RFC 2822 (which obsoletes 822)
has more to say on the subject as it was written a good few years
later.

> And, even if that were the intent of the authors, it is not clear and
> thus very much open to interpretation.
>> 2822 is certainly more extensive, but I don't think it adds anything
>> to the present discussion. For example, I'm not aware of any mail
>> clients that use the References header, or that allow a message to be
>> in reply to more than one originating message (such clients may of
>> course exist, in which case it would be interesting to know about
>> them). RFCs often specify stuff that most clients don't implement,
>> e.g. not many people know that you can have a mail message with
>> multiple From: headers (the canonical example is a message sent by a
>> committee, each member of which appears in the From: line with their
>> own address). I've never seen such a message and I doubt I could
>> construct one with any of the clients I use, but the RFCs allow it.
>>
>>
> Thunderbird uses the "References" header.  If you were to reply to a
> virgin message and examine the outgoing message you'd notice that it
> adds the "In-Reply-To" and "References" headers which are identical.  If
> you reply to a non-virgin message it adds the "In-Reply-To"  header with
> the single message id of the non-virgin message and appends that to the
> "References" header.

Evolution also does this. That isn't the point: creating the
References header is relatively simple. When I say "uses" I mean "pays
attention to in incoming mail". Can you give a specific example where
the MUA uses the References header to display messages (i.e. derives
some information from it that is not present in the In-Reply-To
header, other than simply copying it to further replies)? I don't say
this never happens, just that it would seem at best to be rare. IOW,
everyday threading uses the In-Reply-To header, which is my original
point.

> T-bird also uses the "Subject" line as a hint to threading to assist it
> displaying threads when certain MUAs don't handle the "References"
> header...as it strips it out on a reply.  As in violates the RFCs.

Does it favour Subject over In-Reply-To? Evolution also has an option
to take Subject into account, but only as a last resort.

> FWIW, not many people know that the "From" header in the message body
> may be totally different from the "From" in the SMTP envelope and that
> the "From" header isn't used for message transport or delivery.

They also don't know the difference between From and Sender, so what
else is new? :-)

poc