#599309 mutt: Reply->Postpone->Recall loses message associations

Package:
mutt
Source:
mutt
Description:
text-based mailreader supporting MIME, GPG, PGP and threading
Submitter:
Toni Mueller
Date:
2022-05-06 21:18:02 UTC
Severity:
wishlist
Tags:
#599309#5
Date:
2010-10-06 15:25:30 UTC
From:
To:
Hi,

when I reply to a message, then postpone the reply, then (later) recall
that message to complete the reply, the association between the original
message that I replied to, and the reply I send, are both lost. Neither
is the message I reply to marked as having been replied to, nor does the
new message carry a References: nor a In-Reply-To: header, which results
in these two messages being sorted into two unrelated threads, instead
of one.

I'm pretty sure that this is an upstream issue.


Kind regards,
--Toni++
#599309#10
Date:
2010-10-09 03:02:51 UTC
From:
To:
Am 2010-10-06 17:25:30, schrieb Toni Mueller:

I can confirm this too.

The message can not be maked as "Replied", because if you  POSTPONE  the
message you can even delete the POSTPONED message and it would result in
a wrong "Replied" Flag.  The "Replied" Flag is set, IF  the  message  is
sent.

Since I use:

mutt:
  Installiert: 1.5.20-5~bpo50+1
  Kandidat: 1.5.20-5~bpo50+1
  Versions-Tabelle:
 *** 1.5.20-5~bpo50+1 0
        600 http://www.backports.org lenny-backports/main Packages
        100 /var/lib/dpkg/status
     1.5.18-6 0
        900 ftp://ftp2.de.debian.org lenny/main Packages

I definitively can NOT confirm this.  Since I filter each mailingist in
a seperated INBOX, "theating" message is  working  perfectly  since  it
does not use "In-Reply-To:" but "Message-Id:" and  "References:"  which
are set correctly.

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
#599309#15
Date:
2010-10-11 08:23:31 UTC
From:
To:
The "Replied" flag should imho be set if and only if the email intended
as the reply is actually sent. As long as we can assume that mutt is
the only program working with postponed messages, and as long as mutt
would keep track of where it stored which message (ie, Message-ID <->
mail location), this should be within reach - mutt needed to access the
message being replied to and set the "Replied" flag. For remote
storages (eg. IMAP), this could require maintaining a transaction log,
but I don't see a principal problem doing this, only (likely) quite a
bit of work.


Kind regards,
--Toni++
#599309#20
Date:
2010-10-15 15:36:18 UTC
From:
To:
Am 2010-10-11 10:23:31, schrieb Toni Mueller:
unique identifier, which mean,  the  IMAP-Server  can  rename  the  file
whenever it is neccesary to keep the Maildir consistent.

EVEN "header_cache" can not cope with it.

...and if you move the ORIGINATING message?

The IMAP server does not care about "Message-Id:".

I have currently 208 Mailfolder for mailinglists and the  "header_cache"
is arround 402 MByte.  Adding additional location infos  would  increase
the "header_cache2 by the factor 3.

And if peopls use mutt + IMAP + $HOME on NFS, reading such header  cache
each time you access a mailfolder is absolutely inacceptable.

This additional "location info" would have a heavy performance impact.

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
#599309#27
Date:
2010-12-30 13:56:51 UTC
From:
To:
tag 599309 +confirmed upstream
thanks

Hi Toni,
thanks for your report, I will forward this issue upstream.

Cheers
Antonio
#599309#32
Date:
2022-05-06 21:14:51 UTC
From:
To:
The threading issue was fixed upstream in commits

1) 3c44f482
    <https://gitlab.com/muttmua/mutt/-/commit/3c44f482f97bb9a8ac15007766f82080243ebbc5>

2) 31bc8262
    <https://gitlab.com/muttmua/mutt/-/commit/31bc8262a3c613b9ef15a9e66138343237452a13>

The second commit was released with Mutt 1.8.0.

This should set reply flag in parent *provided* you are still in the
same mailbox when you recall the message.

If you believe this addresses the issue adequately, please feel free to
close it.  Thank you.