Re: [PATCH] test: Add test for searching of uncommonly encoded messages
authorSerge Z <triumhiz@yandex.ru>
Fri, 24 Feb 2012 07:57:00 +0000 (11:57 +0400)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:44:53 +0000 (09:44 -0800)
db/9d98d351374f8feecb6c077dd30bad38aab685 [new file with mode: 0644]

diff --git a/db/9d98d351374f8feecb6c077dd30bad38aab685 b/db/9d98d351374f8feecb6c077dd30bad38aab685
new file mode 100644 (file)
index 0000000..6a90a0f
--- /dev/null
@@ -0,0 +1,125 @@
+Return-Path: <triumhiz@yandex.ru>\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 25CF0431FBC\r
+       for <notmuch@notmuchmail.org>; Thu, 23 Feb 2012 23:54:14 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 1.146\r
+X-Spam-Level: *\r
+X-Spam-Status: No, score=1.146 tagged_above=-999 required=5\r
+       tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+       RCVD_IN_BL_SPAMCOP_NET=1.246, RCVD_IN_DNSWL_NONE=-0.0001]\r
+       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 a5PVBYPZWIG4 for <notmuch@notmuchmail.org>;\r
+       Thu, 23 Feb 2012 23:54:13 -0800 (PST)\r
+Received: from forward8.mail.yandex.net (forward8.mail.yandex.net\r
+       [77.88.61.38])\r
+       by olra.theworths.org (Postfix) with ESMTP id 4E573431FAE\r
+       for <notmuch@notmuchmail.org>; Thu, 23 Feb 2012 23:54:13 -0800 (PST)\r
+Received: from smtp7.mail.yandex.net (smtp7.mail.yandex.net [77.88.61.55])\r
+       by forward8.mail.yandex.net (Yandex) with ESMTP id 994B3F621CD\r
+       for <notmuch@notmuchmail.org>; Fri, 24 Feb 2012 11:54:09 +0400 (MSK)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;\r
+       t=1330070049; bh=D3ossLmvdziNqa8crZWTpQsRO0my2YfBzLjCgTFP8RI=;\r
+       h=Content-Type:MIME-Version:Content-Transfer-Encoding:From:To:\r
+       References:In-Reply-To:Message-ID:Subject:Date;\r
+       b=Q9FRC+BbL3shtKCvoftRS2mAhIeUPx9+P326TNVRwkBeeivwCo1LxP/mouKsQAmjk\r
+       E+n4ajdYuzveKqp0ytC6prq46yBOVKOgDJix+7vDpr2yTN910GnxcCdaV7rmSGI54w\r
+       PulUeRnADexPi33GJOocjQxOgkQH2MS+3csHQ6wU=\r
+Received: from smtp7.mail.yandex.net (localhost [127.0.0.1])\r
+       by smtp7.mail.yandex.net (Yandex) with ESMTP id 7B37815803AA\r
+       for <notmuch@notmuchmail.org>; Fri, 24 Feb 2012 11:54:09 +0400 (MSK)\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail;\r
+       t=1330070049; bh=D3ossLmvdziNqa8crZWTpQsRO0my2YfBzLjCgTFP8RI=;\r
+       h=Content-Type:MIME-Version:Content-Transfer-Encoding:From:To:\r
+       References:In-Reply-To:Message-ID:Subject:Date;\r
+       b=Q9FRC+BbL3shtKCvoftRS2mAhIeUPx9+P326TNVRwkBeeivwCo1LxP/mouKsQAmjk\r
+       E+n4ajdYuzveKqp0ytC6prq46yBOVKOgDJix+7vDpr2yTN910GnxcCdaV7rmSGI54w\r
+       PulUeRnADexPi33GJOocjQxOgkQH2MS+3csHQ6wU=\r
+Received: from host-158-152-66-217.spbmts.ru (host-158-152-66-217.spbmts.ru\r
+       [217.66.152.158])\r
+       by smtp7.mail.yandex.net (nwsmtp/Yandex) with ESMTP id\r
+       s7Q0RJVT-s8Q0oiH5; Fri, 24 Feb 2012 11:54:08 +0400\r
+X-Yandex-Spam: 1\r
+Content-Type: text/plain; charset="utf-8"\r
+MIME-Version: 1.0\r
+Content-Transfer-Encoding: quoted-printable\r
+From: Serge Z <triumhiz@yandex.ru>\r
+User-Agent: alot/0.21+\r
+To: notmuch@notmuchmail.org\r
+References: <877gzd5axk.fsf@steelpick.2x.cz>\r
+       <1330043595-22054-1-git-send-email-sojkam1@fel.cvut.cz>\r
+       <20120224042925.2870.87924@localhost> <874nug67il.fsf@steelpick.2x.cz>\r
+In-Reply-To: <874nug67il.fsf@steelpick.2x.cz>\r
+Message-ID: <20120224075700.13214.28221@localhost>\r
+Subject: Re: [PATCH] test: Add test for searching of uncommonly encoded\r
+       messages\r
+Date: Fri, 24 Feb 2012 11:57:00 +0400\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: Fri, 24 Feb 2012 07:54:14 -0000\r
+\r
+\r
+Quoting Michal Sojka (2012-02-24 11:00:02)\r
+>On Fri, 24 Feb 2012, Serge Z wrote:\r
+>> =\r
+\r
+>> Quoting Michal Sojka (2012-02-24 04:33:15)\r
+>> >Emails that are encoded differently than as ASCII or UTF-8 are not\r
+>> >indexed properly by notmuch. It is not possible to search for non-ASCII\r
+>> >words within those messages.\r
+>> =\r
+\r
+>> Ok. But we can preprocess each incoming message right after 'getmail' to\r
+>> convert it from html to text and to utf8 encoding. One solution is to cr=\r
+eate a\r
+>> seperate script for this and make gmail pipe all messages to this script=\r
+, and\r
+>> then to notmuch. But It would be better if maildir contains original mes=\r
+sages\r
+>> only, so the question is: can we make nomuch indexing engine to index\r
+>> preprocessed message while maildir will contain original message - as it=\r
+ was\r
+>> obtained?\r
+>\r
+>Hi,\r
+>\r
+>I'm not big fan of adding "preprocessor". First, I thing that both\r
+>reasons you mention are actually bugs and it would be better to fix them\r
+>for everybody than requiring each user to configure some preprocessor.\r
+>Second, depending on what and how would your preprocessor do, the\r
+>initial mail indexing could be a way slower, which is also nothing that\r
+>people want.\r
+>\r
+>Do you have any other use case for the preprocessor besides utf8 and\r
+>html->text conversions?\r
+>\r
+>Cheers,\r
+>-Michal\r
+\r
+Well, I don't want to add any external preprocessor too.\r
+\r
+This may be considered as an architectural decision: search engine should n=\r
+ot\r
+access messages directly, but through some preprocessing layer which would\r
+handle the case of different encodings in body and headers, RFC2047-encoded\r
+headers (if this is not handled yet) etc.\r
+\r
+Anyway, this solution imho would be nice to be concluded inside a separate\r
+library which would be useful for notmuch clients as well as other mail\r
+indexing engines. Or an existing library should be looked for.\r
+\r