Re: [PATCH 1/2] python: add classes to wrap all notmuch_*_t types
[notmuch-archives.git] / 1a / 0fc1e425e5f21035550039367899729beb80fb
1 Return-Path: <cworth@cworth.org>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id F121940D168\r
6         for <notmuch@notmuchmail.org>; Fri, 29 Oct 2010 17:19:19 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -2.89\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
13         autolearn=ham\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id MBmZpsnM-QwB; Fri, 29 Oct 2010 17:19:08 -0700 (PDT)\r
17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
18         by olra.theworths.org (Postfix) with ESMTP id 63F5A40D150;\r
19         Fri, 29 Oct 2010 17:19:08 -0700 (PDT)\r
20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
21         id 030F6254007; Fri, 29 Oct 2010 17:19:08 -0700 (PDT)\r
22 From: Carl Worth <cworth@cworth.org>\r
23 To: Michal Sojka <sojkam1@fel.cvut.cz>,\r
24  Igor Shenderovich <shender.i@gmail.com>,       notmuch@notmuchmail.org\r
25 Subject: Re: utf-8 in author field\r
26 In-Reply-To: <87vdanrmfo.fsf@steelpick.2x.cz>\r
27 References: <AANLkTilbzkZSQ0fJd_xtA6gq1QbitGgKA8sV3Mt_uoYv@mail.gmail.com>\r
28         <87vdanrmfo.fsf@steelpick.2x.cz>\r
29 User-Agent: Notmuch/0.3.1 (http://notmuchmail.org) Emacs/23.2.1\r
30         (i486-pc-linux-gnu)\r
31 Date: Fri, 29 Oct 2010 17:19:07 -0700\r
32 Message-ID: <87pquspm6c.fsf@yoom.home.cworth.org>\r
33 MIME-Version: 1.0\r
34 Content-Type: multipart/signed; boundary="=-=-=";\r
35         micalg=pgp-sha1; protocol="application/pgp-signature"\r
36 X-BeenThere: notmuch@notmuchmail.org\r
37 X-Mailman-Version: 2.1.13\r
38 Precedence: list\r
39 List-Id: "Use and development of the notmuch mail system."\r
40         <notmuch.notmuchmail.org>\r
41 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
42         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
43 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
44 List-Post: <mailto:notmuch@notmuchmail.org>\r
45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
46 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
47         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
48 X-List-Received-Date: Sat, 30 Oct 2010 00:19:20 -0000\r
49 \r
50 --=-=-=\r
51 Content-Transfer-Encoding: quoted-printable\r
52 \r
53 On Mon, 17 May 2010 09:56:27 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrot=\r
54 e:\r
55 > On Fri, 14 May 2010, Igor Shenderovich wrote:\r
56 > > What should one do to see the true list of authors?\r
57 >=20\r
58 > I encounter the same when headers are not encoded properly according to\r
59 > RFC 2047. I commonly see the violation of section 5, paragraph (3),\r
60 > sentence "An 'encoded-word' MUST NOT appear within a 'quoted-string'".\r
61 > That is when the encoded word is enclosed in double quotes. I guess, the\r
62 > "problem" is not only notmuch related, but all users of gmime library\r
63 > must be affected.\r
64 \r
65 Thanks for that explanation, Michal.\r
66 \r
67 Igor, does that explanation seem correct for the situation you have?\r
68 \r
69 > I use the following patch for notmuch to sanitize headers from a popular\r
70 > mailing list server in Czech republic:\r
71 \r
72 Obviously that patch is a little too specific to be considered for\r
73 upstream notmuch. But I'm curious to know if there's anything general\r
74 that we could do in notmuch?\r
75 \r
76 My guess is that the best we could do is to come up with some heuristics\r
77 for recognizing a non-RFC-compliant header here and munging it. And the\r
78 heuristics could then fail with messages that were RFC-compliant and\r
79 intentionally including a string of characters that would match the\r
80 heuristic, (which would presumably be rare, but not impossible---so\r
81 perhaps we would then need some configuration).\r
82 \r
83 Anyway, if one of you could send an example of a misbehaving message, I\r
84 might like to look at it and perhaps add it to the test suite to see if\r
85 there's anything we can safely do about it.\r
86 \r
87 =2DCarl\r
88 \r
89 =2D-=20\r
90 carl.d.worth@intel.com\r
91 \r
92 --=-=-=\r
93 Content-Type: application/pgp-signature\r
94 \r
95 -----BEGIN PGP SIGNATURE-----\r
96 Version: GnuPG v1.4.10 (GNU/Linux)\r
97 \r
98 iD8DBQFMy2R76JDdNq8qSWgRAu6cAJ9uX4yItqF4VXLnWYtPQU1pL0HuTgCcDPYf\r
99 Gn78bXKCRUkj2XFjq/m7AO0=\r
100 =ex+u\r
101 -----END PGP SIGNATURE-----\r
102 --=-=-=--\r