Re: utf-8 in author field
authorCarl Worth <cworth@cworth.org>
Sat, 30 Oct 2010 00:19:07 +0000 (17:19 +1700)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:37:20 +0000 (09:37 -0800)
1a/0fc1e425e5f21035550039367899729beb80fb [new file with mode: 0644]

diff --git a/1a/0fc1e425e5f21035550039367899729beb80fb b/1a/0fc1e425e5f21035550039367899729beb80fb
new file mode 100644 (file)
index 0000000..458dcf1
--- /dev/null
@@ -0,0 +1,102 @@
+Return-Path: <cworth@cworth.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 F121940D168\r
+       for <notmuch@notmuchmail.org>; Fri, 29 Oct 2010 17:19:19 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.89\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
+       tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
+       autolearn=ham\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 MBmZpsnM-QwB; Fri, 29 Oct 2010 17:19:08 -0700 (PDT)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 63F5A40D150;\r
+       Fri, 29 Oct 2010 17:19:08 -0700 (PDT)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 030F6254007; Fri, 29 Oct 2010 17:19:08 -0700 (PDT)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Michal Sojka <sojkam1@fel.cvut.cz>,\r
+ Igor Shenderovich <shender.i@gmail.com>,      notmuch@notmuchmail.org\r
+Subject: Re: utf-8 in author field\r
+In-Reply-To: <87vdanrmfo.fsf@steelpick.2x.cz>\r
+References: <AANLkTilbzkZSQ0fJd_xtA6gq1QbitGgKA8sV3Mt_uoYv@mail.gmail.com>\r
+       <87vdanrmfo.fsf@steelpick.2x.cz>\r
+User-Agent: Notmuch/0.3.1 (http://notmuchmail.org) Emacs/23.2.1\r
+       (i486-pc-linux-gnu)\r
+Date: Fri, 29 Oct 2010 17:19:07 -0700\r
+Message-ID: <87pquspm6c.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\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: Sat, 30 Oct 2010 00:19:20 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Mon, 17 May 2010 09:56:27 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrot=\r
+e:\r
+> On Fri, 14 May 2010, Igor Shenderovich wrote:\r
+> > What should one do to see the true list of authors?\r
+>=20\r
+> I encounter the same when headers are not encoded properly according to\r
+> RFC 2047. I commonly see the violation of section 5, paragraph (3),\r
+> sentence "An 'encoded-word' MUST NOT appear within a 'quoted-string'".\r
+> That is when the encoded word is enclosed in double quotes. I guess, the\r
+> "problem" is not only notmuch related, but all users of gmime library\r
+> must be affected.\r
+\r
+Thanks for that explanation, Michal.\r
+\r
+Igor, does that explanation seem correct for the situation you have?\r
+\r
+> I use the following patch for notmuch to sanitize headers from a popular\r
+> mailing list server in Czech republic:\r
+\r
+Obviously that patch is a little too specific to be considered for\r
+upstream notmuch. But I'm curious to know if there's anything general\r
+that we could do in notmuch?\r
+\r
+My guess is that the best we could do is to come up with some heuristics\r
+for recognizing a non-RFC-compliant header here and munging it. And the\r
+heuristics could then fail with messages that were RFC-compliant and\r
+intentionally including a string of characters that would match the\r
+heuristic, (which would presumably be rare, but not impossible---so\r
+perhaps we would then need some configuration).\r
+\r
+Anyway, if one of you could send an example of a misbehaving message, I\r
+might like to look at it and perhaps add it to the test suite to see if\r
+there's anything we can safely do about it.\r
+\r
+=2DCarl\r
+\r
+=2D-=20\r
+carl.d.worth@intel.com\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iD8DBQFMy2R76JDdNq8qSWgRAu6cAJ9uX4yItqF4VXLnWYtPQU1pL0HuTgCcDPYf\r
+Gn78bXKCRUkj2XFjq/m7AO0=\r
+=ex+u\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r