--- /dev/null
+Return-Path: <jani@nikula.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 00C21431FB6\r
+ for <notmuch@notmuchmail.org>; Tue, 26 Feb 2013 01:19:23 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[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 7lMT0nEj4WZN for <notmuch@notmuchmail.org>;\r
+ Tue, 26 Feb 2013 01:19:20 -0800 (PST)\r
+Received: from mail-we0-f175.google.com (mail-we0-f175.google.com\r
+ [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 52D14431FAF\r
+ for <notmuch@notmuchmail.org>; Tue, 26 Feb 2013 01:19:20 -0800 (PST)\r
+Received: by mail-we0-f175.google.com with SMTP id x8so3317447wey.6\r
+ for <notmuch@notmuchmail.org>; Tue, 26 Feb 2013 01:19:17 -0800 (PST)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=google.com; s=20120113;\r
+ h=x-received:from:to:subject:in-reply-to:references:user-agent:date\r
+ :message-id:mime-version:content-type:x-gm-message-state;\r
+ bh=fumzV0OKnmDWKk9etUJm2gd9dTO/IAToWlwm722R27Q=;\r
+ b=l550UJYCKGunAujYO8aZVnSFVCGKoAEjkAGFiOijNfeyfSOUpnnTw1BDAIpcHNH55o\r
+ uqWmLbVztjgJ/wlHaOBcNzGoaElHovcR/O9zZC4sjOCNJujVFcKOuPBJopRTiTibrl6F\r
+ vz1LG+9R55TSmuQlQOhEg29SiYFdORNG1PMBKKY99zq0WdDdOAES2RJToAkyE3TPTy7o\r
+ 8VOtLmtQNPGYCjBTSPIZXGDJ+HL5Nd4nT+IKAh/mJNoMa6wsurNMeE1HyQPU4ApCMXu4\r
+ /om6T1ohN8cWsBN7Mco+xSshgobofMjDectLbXsTYbaAfMCbO3YUNG7uAel/FhH7avnG\r
+ AMPw==\r
+X-Received: by 10.180.92.39 with SMTP id cj7mr17802562wib.19.1361870357808;\r
+ Tue, 26 Feb 2013 01:19:17 -0800 (PST)\r
+Received: from localhost ([2001:4b98:dc0:43:216:3eff:fe1b:25f3])\r
+ by mx.google.com with ESMTPS id bj9sm19843333wib.4.2013.02.26.01.19.15\r
+ (version=TLSv1.1 cipher=RC4-SHA bits=128/128);\r
+ Tue, 26 Feb 2013 01:19:16 -0800 (PST)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Aaron Ecay <aaronecay@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: [RFC] [PATCH] lib/database.cc: change how the parent of a message\r
+ is calculated\r
+In-Reply-To: <1361836225-17279-1-git-send-email-aaronecay@gmail.com>\r
+References: <1361836225-17279-1-git-send-email-aaronecay@gmail.com>\r
+User-Agent: Notmuch/0.14+259~gdee88db (http://notmuchmail.org) Emacs/23.2.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Tue, 26 Feb 2013 10:19:06 +0100\r
+Message-ID: <878v6bjuut.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-Gm-Message-State:\r
+ ALoCoQlx3ALbGyQhHxtVa2iEPQQ0nC850x2OiuzgcWKxG64wFqbLyFq+Uzo+nSwk1lSSdYs/S+Xe\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: Tue, 26 Feb 2013 09:19:23 -0000\r
+\r
+On Tue, 26 Feb 2013, Aaron Ecay <aaronecay@gmail.com> wrote:\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
+Hi Aaron, please provide references to a few messages like this. If\r
+available on the notmuch list an id: reference would be best, but\r
+otherwise some archive that allows viewing full message headers or\r
+downloading the full message would be best.\r
+\r
+Thanks,\r
+Jani.\r
+\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
+> _______________________________________________\r
+> notmuch mailing list\r
+> notmuch@notmuchmail.org\r
+> http://notmuchmail.org/mailman/listinfo/notmuch\r