BUG?: The UI shows an "In-Reply-To" value different than the actual value

BUG?: The UI shows an "In-Reply-To" value different than the actual value

[Ævar Arnfjörð Bjarmason]

(I'm not on-list, please keep me CC'd)

Maybe I'm being evil, but when I talk about another E-Mail I add it to
the "References" header. Reading
https://tools.ietf.org/html/rfc5322#section-3.6.4 this may be more evil
than I thought at first.

Anyway, if you look at
https://public-inbox.org/git/87va4szr2q.fsf@evledraar.gmail.com/ you can
see one such E-Mail. The UI shows:

    In-Reply-To: <874lcd1bub.fsf@evledraar.gmail.com>

But as the "raw" view shows these are the actual headers:

    References: <9e293b1b-1845-1772-409b-031c0bf4d17b@gmail.com>
            <871s7g29zy.fsf@evledraar.gmail.com>
            <6f0ff2e3-4019-1dcc-f61a-cd0919b9a247@gmail.com>
            <874lcd1bub.fsf@evledraar.gmail.com>
    In-reply-to: <6f0ff2e3-4019-1dcc-f61a-cd0919b9a247@gmail.com>

I'd expect the web UI to show the value of the header in its primary
view.

Re: BUG?: The UI shows an "In-Reply-To" value different than the actual value

[Eric Wong]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> (I'm not on-list, please keep me CC'd)

Yep, it's expected and strongly encouraged behavior here to
reply-all :) Centralization is the enemy, and I don't expect
many people are subscribed to this list.

> Maybe I'm being evil, but when I talk about another E-Mail I add it to
> the "References" header. Reading
> https://tools.ietf.org/html/rfc5322#section-3.6.4 this may be more evil
> than I thought at first.

This part of RFC 5322?

      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; how to do so is not defined in this
      document.

Yes, public-inbox does treat the order of References as significant.

> Anyway, if you look at
> https://public-inbox.org/git/87va4szr2q.fsf@evledraar.gmail.com/ you can
> see one such E-Mail. The UI shows:
> 
>     In-Reply-To: <874lcd1bub.fsf@evledraar.gmail.com>
> 
> But as the "raw" view shows these are the actual headers:
> 
>     References: <9e293b1b-1845-1772-409b-031c0bf4d17b@gmail.com>
>             <871s7g29zy.fsf@evledraar.gmail.com>
>             <6f0ff2e3-4019-1dcc-f61a-cd0919b9a247@gmail.com>
>             <874lcd1bub.fsf@evledraar.gmail.com>
>     In-reply-to: <6f0ff2e3-4019-1dcc-f61a-cd0919b9a247@gmail.com>
> 
> I'd expect the web UI to show the value of the header in its primary
> view.

Yes, I understand how that can be disconcerting...

Perhaps the View.pm code can actually use the In-Reply-To header
if it exists, but that may throw off the thread skeleton code
and Xapian index.


When I was working on this, I found References: more consistent
and easier-to-parse than In-Reply-To; as the latter could
contain random human-readable phrases.  Thus the code favors
using the References header for threading.

lib/PublicInbox/MID.pm has this, currently:

	# last References should be IRT, but some mail clients do things
	# out of order, so trust IRT over References iff IRT exists
	sub references ($) {
		my ($hdr) = @_;
		my @mids;
		foreach my $f (qw(References In-Reply-To)) {
			my @v = $hdr->header_raw($f);
			foreach my $v (@v) {
				push(@mids, ($v =~ /<([^>]+)>/sg));
			}
		}
		uniq_mids(\@mids);
	}

So, it appears the comment and code don't match (it's been a
while :x).  Maybe this is needed, too?

diff --git a/lib/PublicInbox/MID.pm b/lib/PublicInbox/MID.pm
index cd56f27..a775fdc 100644
--- a/lib/PublicInbox/MID.pm
+++ b/lib/PublicInbox/MID.pm
@@ -79,7 +79,9 @@ ($)
 			push(@mids, ($v =~ /<([^>]+)>/sg));
 		}
 	}
+	@mids = reverse(@mids);
 	uniq_mids(\@mids);
+	[ reverse(@mids) ];
 }
 
 sub uniq_mids ($) {


Note: untested.

Re: BUG?: The UI shows an "In-Reply-To" value different than the actual value

[Leah Neukirchen]

Eric Wong <e@80x24.org> writes:

> When I was working on this, I found References: more consistent
> and easier-to-parse than In-Reply-To; as the latter could
> contain random human-readable phrases.  Thus the code favors
> using the References header for threading.
>
> lib/PublicInbox/MID.pm has this, currently:
>
> 	# last References should be IRT, but some mail clients do things
> 	# out of order, so trust IRT over References iff IRT exists

This is also what jwz recommends (https://www.jwz.org/doc/threading.html):

>> I've been informed that recent versions of Eudora violate this
>> standard: they put the parent Message-ID in the In-Reply-To header,
>> but do not duplicate it in the References header: instead, the
>> References header contains the grandparent, great-grand-parent,
>> etc.
>> This implies that to properly reconstruct the thread of a message
>> in the face of this nonstandard behavior, we need to append any
>> In-Reply-To message IDs to References.

(mthread(1) of mblaze does the same.)

-- 
Leah Neukirchen  <leah@vuxu.org>  http://leah.zone