On Fri 2017-07-14 15:09:12 +0200, Daniel Kahn Gillmor wrote:
> The reply-to munging code might behave differently whether there's an
> exact match on the strings or not, or whether the string is a raw
> addr-spec instead of an name-addr.  These tests cover those
> variations.

This pair of patches should be safe and clean to apply.  When they're
applied, though, the gmime 3.0 series no longer passes the test suite
due to these failures:

----------
T220-reply: Testing "notmuch reply" in several variations
 PASS   Basic reply
 PASS   Multiple recipients
 PASS   Reply with CC
 PASS   Reply from alternate address
 PASS   Reply from address in named group list
 PASS   Support for Reply-To
 FAIL   Un-munging Reply-To
	--- T220-reply.7.expected	2017-07-14 13:24:32.203184911 +0000
	+++ T220-reply.7.output	2017-07-14 13:24:32.203184911 +0000
	@@ -6,3 +6,4 @@
	 
	 On Tue, 05 Jan 2010 15:43:56 -0000, Sender <sender@example.com> wrote:
	 > Un-munging Reply-To
	+failed
 FAIL   Un-munging Reply-To With Exact Match
	--- T220-reply.8.expected	2017-07-14 13:24:32.243185095 +0000
	+++ T220-reply.8.output	2017-07-14 13:24:32.243185095 +0000
	@@ -6,3 +6,4 @@
	 
	 On Tue, 05 Jan 2010 15:43:56 -0000, Sender <sender@example.com> wrote:
	 > Un-munging Reply-To
	+failed
 PASS   Un-munging Reply-To With Raw addr-spec
 PASS   Message with header of exactly 200 bytes
 PASS   From guessing: Envelope-To
 PASS   From guessing: X-Original-To
 PASS   From guessing: Delivered-To
 PASS   Reply with RFC 2047-encoded headers
 PASS   Reply with RFC 2047-encoded headers (JSON)
 PASS   Reply to a message with multiple Cc headers
----------

I think this is due to "notmuch reply" crashing on those first two tests
with a segmentation fault.

i think this implicates the reply-to munging code, which i don't
understand, but would welcome help on debugging.

            --dkg