--- /dev/null
+Return-Path: <aaronecay@gmail.com>\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 3D002431FB6\r
+ for <notmuch@notmuchmail.org>; Mon, 25 Feb 2013 15:50:50 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.799\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
+ tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+ FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 Idp4XA5TlSoJ for <notmuch@notmuchmail.org>;\r
+ Mon, 25 Feb 2013 15:50:48 -0800 (PST)\r
+Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com\r
+ [209.85.216.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 28145431FAF\r
+ for <notmuch@notmuchmail.org>; Mon, 25 Feb 2013 15:50:48 -0800 (PST)\r
+Received: by mail-qa0-f43.google.com with SMTP id dx4so1998837qab.16\r
+ for <notmuch@notmuchmail.org>; Mon, 25 Feb 2013 15:50:46 -0800 (PST)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
+ h=x-received:from:to:subject:date:message-id:x-mailer;\r
+ bh=Gb97bSBCXF90gLJGKBgLDpgYym8VnFeXujv5M97o9x4=;\r
+ b=JBIhP3PVm+K6TEtLSNMpWdiQw47wdDy8cC5qTluNPjMfo2j6nLMRlYGcUBdS1P0fEn\r
+ csEt6PN0FqXyrhcR1QTKPPvY7exswlndQ1jn9i6dae714hBL+na0gOZ6u+8+5vcZ+SAe\r
+ z+5pyTkZwLDZMJy2If9KXFpJJN71RiOkv0LDD3ULM11mscKo3RAVtLMkQoQTsE4CJPcq\r
+ Jqio7PckpojytDDFJfl8Eehw2J2pnXHtzF/0Q5TJb6lieK7UFVfGBzdRTFkKhlrM9xAd\r
+ LZQUU9BI6GXelR3KSkrUchsJZB6ZBZ0B7ikfAMQ6bFh3Lld/Ka1eSxosSgE2xR++obR4\r
+ jJ1w==\r
+X-Received: by 10.49.96.33 with SMTP id dp1mr16646678qeb.60.1361836245427;\r
+ Mon, 25 Feb 2013 15:50:45 -0800 (PST)\r
+Received: from localhost.localdomain\r
+ (vagvlan532.239.wlan.wireless-pennnet.upenn.edu. [128.91.71.113])\r
+ by mx.google.com with ESMTPS id hr3sm19437068qab.4.2013.02.25.15.50.39\r
+ (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128);\r
+ Mon, 25 Feb 2013 15:50:44 -0800 (PST)\r
+From: Aaron Ecay <aaronecay@gmail.com>\r
+To: notmuch@notmuchmail.org\r
+Subject: [RFC] [PATCH] lib/database.cc: change how the parent of a message is\r
+ calculated\r
+Date: Mon, 25 Feb 2013 18:50:25 -0500\r
+Message-Id: <1361836225-17279-1-git-send-email-aaronecay@gmail.com>\r
+X-Mailer: git-send-email 1.8.1.4\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: Mon, 25 Feb 2013 23:50:50 -0000\r
+\r
+Presently, the code which finds the parent of a message as it is being\r
+added to the database assumes that the first Message-ID-like substring\r
+of the In-Reply-To header is the parent Message ID. Some mail clients,\r
+however, put stuff other than the Message-ID of the parent in the\r
+In-Reply-To header, such as the email address of the sender of the\r
+parent. This can fool notmuch.\r
+\r
+The updated algorithm prefers the last Message ID in the References\r
+header. The References header lists messages oldest-first, so the last\r
+Message ID is the parent (RFC2822, p. 24). The References header is\r
+also less likely to be in a non-standard\r
+syntax (http://cr.yp.to/immhf/thread.html,\r
+http://www.jwz.org/doc/threading.html). In case the References header\r
+is not to be found, fall back to the old behavior.\r
+---\r
+\r
+I especially notice this problem on public mailing lists, where\r
+certain people's messages always cause an "out-dent" of the threading,\r
+instead of being nested under whichever message they are replies to.\r
+\r
+Technically, putting non-Message-ID crud in the In-Reply-To field is a\r
+violation of RFC2822, but it appears that in practice the References\r
+header is respected more often than the In-Reply-To one.\r
+\r
+ lib/database.cc | 30 ++++++++++++++++++++++--------\r
+ 1 file changed, 22 insertions(+), 8 deletions(-)\r
+\r
+diff --git a/lib/database.cc b/lib/database.cc\r
+index 91d4329..cbf33ae 100644\r
+--- a/lib/database.cc\r
++++ b/lib/database.cc\r
+@@ -501,8 +501,10 @@ _parse_message_id (void *ctx, const char *message_id, const char **next)\r
+ * 'message_id' in the result (to avoid mass confusion when a single\r
+ * message references itself cyclically---and yes, mail messages are\r
+ * not infrequent in the wild that do this---don't ask me why).\r
++ *\r
++ * Return the last reference parsed.\r
+ */\r
+-static void\r
++static char *\r
+ parse_references (void *ctx,\r
+ const char *message_id,\r
+ GHashTable *hash,\r
+@@ -511,7 +513,7 @@ parse_references (void *ctx,\r
+ char *ref;\r
+\r
+ if (refs == NULL || *refs == '\0')\r
+- return;\r
++ return NULL;\r
+\r
+ while (*refs) {\r
+ ref = _parse_message_id (ctx, refs, &refs);\r
+@@ -519,6 +521,8 @@ parse_references (void *ctx,\r
+ if (ref && strcmp (ref, message_id))\r
+ g_hash_table_insert (hash, ref, NULL);\r
+ }\r
++\r
++ return ref;\r
+ }\r
+\r
+ notmuch_status_t\r
+@@ -1365,7 +1369,7 @@ _notmuch_database_generate_doc_id (notmuch_database_t *notmuch)\r
+ notmuch->last_doc_id++;\r
+\r
+ if (notmuch->last_doc_id == 0)\r
+- INTERNAL_ERROR ("Xapian document IDs are exhausted.\n");\r
++ INTERNAL_ERROR ("Xapian document IDs are exhausted.\n");\r
+\r
+ return notmuch->last_doc_id;\r
+ }\r
+@@ -1509,7 +1513,7 @@ _notmuch_database_link_message_to_parents (notmuch_database_t *notmuch,\r
+ const char **thread_id)\r
+ {\r
+ GHashTable *parents = NULL;\r
+- const char *refs, *in_reply_to, *in_reply_to_message_id;\r
++ const char *refs, *in_reply_to, *in_reply_to_message_id, *last_ref_message_id;\r
+ GList *l, *keys = NULL;\r
+ notmuch_status_t ret = NOTMUCH_STATUS_SUCCESS;\r
+\r
+@@ -1517,21 +1521,31 @@ _notmuch_database_link_message_to_parents (notmuch_database_t *notmuch,\r
+ _my_talloc_free_for_g_hash, NULL);\r
+\r
+ refs = notmuch_message_file_get_header (message_file, "references");\r
+- parse_references (message, notmuch_message_get_message_id (message),\r
+- parents, refs);\r
++ last_ref_message_id = parse_references (message,\r
++ notmuch_message_get_message_id (message),\r
++ parents, refs);\r
+\r
+ in_reply_to = notmuch_message_file_get_header (message_file, "in-reply-to");\r
+ parse_references (message, notmuch_message_get_message_id (message),\r
+ parents, in_reply_to);\r
+\r
+- /* Carefully avoid adding any self-referential in-reply-to term. */\r
+ in_reply_to_message_id = _parse_message_id (message, in_reply_to, NULL);\r
++ /* If the parent message ID from the Reply-To and References\r
++ * headers are different, use the References one. This is because\r
++ * the Reply-To header is more likely to be in an non-standard\r
++ * format. */\r
++ if (in_reply_to_message_id &&\r
++ last_ref_message_id &&\r
++ strcmp (last_ref_message_id, in_reply_to_message_id)) {\r
++ in_reply_to_message_id = last_ref_message_id;\r
++ }\r
++ /* Carefully avoid adding any self-referential in-reply-to term. */\r
+ if (in_reply_to_message_id &&\r
+ strcmp (in_reply_to_message_id,\r
+ notmuch_message_get_message_id (message)))\r
+ {\r
+ _notmuch_message_add_term (message, "replyto",\r
+- _parse_message_id (message, in_reply_to, NULL));\r
++ in_reply_to_message_id);\r
+ }\r
+\r
+ keys = g_hash_table_get_keys (parents);\r
+--\r
+1.8.1.4\r
projects / notmuch-archives.git / commitdiff