From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id D220F431FAF for ; Tue, 10 Sep 2013 15:36:08 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WvW5NP9HuBX for ; Tue, 10 Sep 2013 15:36:02 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by olra.theworths.org (Postfix) with ESMTP id D50BD431FAE for ; Tue, 10 Sep 2013 15:36:01 -0700 (PDT) X-AuditID: 12074423-b7f168e00000095a-d5-522f9ed0189a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 96.52.02394.0DE9F225; Tue, 10 Sep 2013 18:36:00 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r8AMZxQ9002308; Tue, 10 Sep 2013 18:36:00 -0400 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8AMZub7001412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Sep 2013 18:35:58 -0400 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80) (envelope-from ) id 1VJWXK-0000QY-Cj; Tue, 10 Sep 2013 18:35:54 -0400 Date: Tue, 10 Sep 2013 18:35:53 -0400 From: Austin Clements To: Daniel Kahn Gillmor Subject: Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() Message-ID: <20130910223553.GI1426@mit.edu> References: <1378839078-6298-1-git-send-email-jani@nikula.org> <522F73A4.90802@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522F73A4.90802@fifthhorseman.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IRYrdT170wTz/IYNcfKYvW7s9MFtdvzmR2 YPI4293O6vFs1S3mAKYoLpuU1JzMstQifbsEroy1E+6xF+zhrLiyu521gfEKexcjB4eEgIlE e59zFyMnkCkmceHeerYuRi4OIYF9jBJrF29lh3A2MkrM+t7NCuGcZpI4v+MCE4SzhFFi968v jCD9LAKqEgefPGAGsdkENCS27V8OFhcR0Jc4c/cCK4jNDFTTuPYiWI2wQJhE3/FfYHFeAW2J g8cvsoHYQgLJErOb5rBAxAUlTs58wgLRqyVx499LJpCzmQWkJZb/4wAJcwKN/zZxFzuILSqg IjHl5Da2CYxCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdM73czBK91JTS TYzgsHZR3sH456DSIUYBDkYlHt4bcvpBQqyJZcWVuYcYJTmYlER5n84BCvEl5adUZiQWZ8QX leakFh9ilOBgVhLhneoElONNSaysSi3Kh0lJc7AoifOuB0kJpCeWpGanphakFsFkZTg4lCR4 1YDxKyRYlJqeWpGWmVOCkGbi4AQZzgM0PA+khre4IDG3ODMdIn+KUVFKnPfLXJDRIImM0jy4 XljaecUoDvSKMK8VSDsPMGXBdb8CGswENPi7L9jgkkSElFQDo1203/T5y87Nj3jOFHrfmqks buuRqQVvlspfvfZL4Mt+Kz1LDq1fq5cdZBFyKXidwmTCt6N75sfPl70/JC969EOmcGnjocu7 llatmFN6Xa7yYNfG9T+0c3aXVPjUrp3+6720VGeDZ//mnbsf9fz/M23D0+81O2Z8cFhxRjOy TuXoI/tVRrXP7y9RYinOSDTUYi4qTgQAOp7FmxYDAAA= Cc: notmuch X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 22:36:09 -0000 Quoth Daniel Kahn Gillmor on Sep 10 at 3:31 pm: > On 09/10/2013 02:51 PM, Jani Nikula wrote: > > As explained by Jeffrey Stedfast, the author of GMime, quoted in [1]: > > > >> Passing the GMIME_ENABLE_RFC2047_WORKAROUNDS flag to g_mime_init() > >> *should* solve the decoding problem mentioned in the thread. This > >> flag should be safe to pass into g_mime_init() without any bad side > >> effects and my unit tests do test that code-path. > > the result of doing this is that there will become legitimately-crafted > subject lines that are now unrepresentable. > > I'm always leery of trying to improve support for data that doesn't > follow the standards at the expense of data that *does* follow the > standards. > > --dkg I haven't looked at exactly what workarounds this enables, but if it's what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text tokens), are there really subject lines that this will misinterpret that weren't obviously crafted to break the workaround? The RFC 2047 escape sequence was deliberately designed to be obscure, since RFC 2047 itself caused previously "standards-compliant" subject lines to potentially be interpreted differently.