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