Hi all, On Fri, Dec 04 2015, Jani Nikula wrote: > On Fri, 04 Dec 2015, Damien Cassou <damien@cassou.me> wrote: >> David Bremner <david@tethera.net> writes: >> >>> Damien Cassou <damien@cassou.me> writes: >>> >>>> "To" : "rmod@inria.fr", >>>> "Reply-To" : "rmod@inria.fr", >>>> "From" : "seaside@rmod.inria.fr", >>>> "Subject" : "[rmod] [Mm10s] 2015-11-30", >>>> "Date" : "Mon, 30 Nov 2015 07:00:01 +0100" >>> >>> A quick look at the code suggests this is falling victim to the >>> "reply-to munging" detection code, which considers a reply-to field >>> redudant if it duplicates one of the other fields. From the source >>> >>> /* Some mailing lists munge the Reply-To header despite it being A Bad >>> * Thing, see http://www.unicom.com/pw/reply-to-harmful.html >>> * >>> * The munging is easy to detect, because it results in a >>> * redundant reply-to header, (with an address that already exists >>> * in either To or Cc). So in this case, we ignore the Reply-To >>> * field and use the From header. This ensures the original sender >>> * will get the reply even if not subscribed to the list. Note >>> * that the address in the Reply-To header will always appear in >>> * the reply. >>> */ >> >> >> The last sentence seems to contradict my example: >> >> Note that the address in the Reply-To header will always appear in >> the reply. >> >> Here is the reply message, and it does not contain the address in Reply-To. > > This was true way back when notmuch reply only knew about reply all. For > --reply-to=sender, it's broken. The simplest "fix" might be I don't think that this is broken for two reasons: 1. In tests/T230-reply-to-sender.sh, there is "Un-munging Reply-To" test, which checks the same combination of headers as in Damien's case and uses --reply-to=sender. The test passes and the reply has To=From. 2. When replying to mailing lists using reply-to munging, current notmuch behavior allows me to decide whether to reply 1) privately to the mail sender (--reply-to=sender) or 2) to the mailing list (--reply-to=all). The proposed change would make option 1) harder. Therefore I suggest to fix this by applying the documentation patch from the follow-up mail. -Michal