Re: [PATCH] Next attempt to get guessing of From addresses correct in replies

diff --git a/8c/d4286424599480bd32da4f6c8948b4728011e2 b/8c/d4286424599480bd32da4f6c8948b4728011e2
new file mode 100644 (file)
index 0000000..ecbf681
--- /dev/null
+++ b/8c/d4286424599480bd32da4f6c8948b4728011e2
@@ -0,0 +1,114 @@
+Return-Path: <BATV+d1925439303f0e3a7211+2425+infradead.org+hohndel@bombadil.srs.infradead.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 42E68431FC1\r
+       for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 11:57:28 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.301\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5\r
+       tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id bCLaLV9ysBic for <notmuch@notmuchmail.org>;\r
+       Wed, 14 Apr 2010 11:57:26 -0700 (PDT)\r
+Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34])\r
+       by olra.theworths.org (Postfix) with ESMTP id EBE714196F2\r
+       for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 11:57:25 -0700 (PDT)\r
+Received: from localhost ([::1] helo=x200.gr8dns.org)\r
+       by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux))\r
+       id 1O27m9-0007qs-Hd; Wed, 14 Apr 2010 18:57:25 +0000\r
+Received: by x200.gr8dns.org (Postfix, from userid 500)\r
+       id 205BDC00E5; Wed, 14 Apr 2010 11:57:25 -0700 (PDT)\r
+From: Dirk Hohndel <hohndel@infradead.org>\r
+To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH] Next attempt to get guessing of From addresses correct in\r
+       replies\r
+In-Reply-To: <87y6gqeyqh.fsf@yoom.home.cworth.org>\r
+References: <m37hogdyr3.fsf@x200.gr8dns.org>\r
+       <87y6gqeyqh.fsf@yoom.home.cworth.org>\r
+Date: Wed, 14 Apr 2010 11:57:25 -0700\r
+Message-ID: <m3mxx5amlm.fsf@x200.gr8dns.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-SRS-Rewrite: SMTP reverse-path rewritten from <hohndel@infradead.org> by\r
+       bombadil.infradead.org See http://www.infradead.org/rpr.html\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 14 Apr 2010 18:57:28 -0000\r
+\r
+On Wed, 14 Apr 2010 10:21:42 -0700, Carl Worth <cworth@cworth.org> wrote:\r
+> On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:\r
+> > + * WARNING - if the caller is asking for a header that could occur\r
+> > + * multiple times than they MUST first call this function with a \r
+> > + * a value of NULL for header_desired to ensure that all of the\r
+> > + * headers are parsed and concatenated before a match is returned\r
+> ...\r
+> > +  } else {\r
+> > +      /* not sure this makes sense for all headers that can occur\r
+> > +       * multiple times, but for now just concatenate headers\r
+> > +       */\r
+> > +      newhdr = strlen(decoded_value);\r
+> > +      hdrsofar = strlen(header_sofar);\r
+> \r
+> I'm a little nervous about this semantic change.\r
+\r
+So am I - but I haven't found a message where this would have bitten me.\r
+ \r
+> For example, I know that my mail collection contains at least some\r
+> messages with multiple Message-ID headers, (I'm not sure that's legal,\r
+> but they are there).\r
+\r
+No, that is absolutely NOT RFC compliant. Wonder what creates those\r
+messages...\r
+\r
+> I found those when doing detailed comparisons of\r
+> the database created by sup with that created by very early versions of\r
+> what became the indexing code for notmuch. [Sup prefers the\r
+> last-encountered Message-Id in the file, while Notmuch prefers the\r
+> first.]\r
+\r
+Actually, prior to another fix that I sent (and that you already\r
+applied), notmuch would use the first if you came across this header for\r
+the first time when searching for it (but since you'd search for\r
+Message-Id fairly early on, that's likely what happened). But if your\r
+header was remembered "en-passant" while searching for a different\r
+header later in the file, notmuch would actually remember the last.\r
+\r
+But again, I fixed that before making the change to concatenate\r
+duplicates instead.\r
+ \r
+> So I'm concerned about the change above introducing subtle problems that\r
+> might be hard to notice.\r
+\r
+Yes, absolutely - a concatenated Message-Id would SUCK.\r
+ \r
+> How about an argument that asks explicitly for concatenated header\r
+> values, (and this could just trigger a rescan of the headers and ignore\r
+> the hash). I think that will be fine for your use case where you're just\r
+> opening this message file to get this one concatenated header out,\r
+> right?\r
+\r
+That would work just fine. And avoid the potential unintended side\r
+effects. \r
+\r
+I'm about to head for the airport - do you want to make that\r
+modification yourself or should I do it tonight?\r
+\r
+/D\r
+\r
+-- \r
+Dirk Hohndel\r
+Intel Open Source Technology Center\r