--- /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 180CF431FAF\r
+ for <notmuch@notmuchmail.org>; Wed, 11 Sep 2013 11:21:43 -0700 (PDT)\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 5je5qsJttItT for <notmuch@notmuchmail.org>;\r
+ Wed, 11 Sep 2013 11:21:35 -0700 (PDT)\r
+Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com\r
+ [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client\r
+ certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
+ 29244431FAE for <notmuch@notmuchmail.org>; Wed, 11 Sep 2013 11:21:35 -0700\r
+ (PDT)\r
+Received: by mail-wg0-f54.google.com with SMTP id e11so7011036wgh.21\r
+ for <notmuch@notmuchmail.org>; Wed, 11 Sep 2013 11:21:34 -0700 (PDT)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:from:to:cc:subject:in-reply-to:references\r
+ :user-agent:date:message-id:mime-version:content-type;\r
+ bh=oEJ5P9HRMlMMSWpyxKWcVX6iHJq78WfkDonNgh2SLVo=;\r
+ b=czZrm9YWXPPV0Hadp2//32pi0qshN8UfCSSMKWyVwFWY+ojoy4eJcnmbJRnXUsP9XL\r
+ 27BkoWojfbTIEy7G6LXxovzQ2etU1sH9BHfnj+frF0opaR+RELXbqKiiA0RMzLFuN6lm\r
+ aWbOomJ26qwRzrkNV78JCVpMxWgz1jVu2B32tGZYRsy/rb10YlQNh2IoWn9uIldmmvA1\r
+ sdGIjFj/xnq0v9ri6es1FhbEOfnEZIr3tm5E3y9swd/ziYDM64AtdCt4R8MKcAYvMLax\r
+ pyngTCLLFnl5EwcI6MZzL1Pm38t5JdKqYQp7RJPzAWsMcZbfw0UAbREUga48L8La81l2\r
+ vNsw==\r
+X-Gm-Message-State:\r
+ ALoCoQkax4J2NXG1bSye2bEZat0e2fcDklKbjFU2mvkkOSGW/WNunjNO7rmxYnRFVGtSn6DGidqM\r
+X-Received: by 10.180.38.73 with SMTP id e9mr2470388wik.31.1378923694059;\r
+ Wed, 11 Sep 2013 11:21:34 -0700 (PDT)\r
+Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi.\r
+ [88.195.111.91])\r
+ by mx.google.com with ESMTPSA id ey2sm12457863wib.5.1969.12.31.16.00.00\r
+ (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
+ Wed, 11 Sep 2013 11:21:33 -0700 (PDT)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
+ Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to\r
+ g_mime_init() a test\r
+In-Reply-To: <522FA24D.8080307@fifthhorseman.net>\r
+References: <1378839078-6298-1-git-send-email-jani@nikula.org>\r
+ <522F73A4.90802@fifthhorseman.net> <20130910223553.GI1426@mit.edu>\r
+ <522FA24D.8080307@fifthhorseman.net>\r
+User-Agent: Notmuch/0.16+75~g1a51174 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Wed, 11 Sep 2013 21:21:34 +0300\r
+Message-ID: <87ob7zp6c1.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+Cc: notmuch <notmuch@notmuchmail.org>\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: Wed, 11 Sep 2013 18:21:43 -0000\r
+\r
+On Wed, 11 Sep 2013, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:\r
+> On 09/10/2013 06:35 PM, Austin Clements wrote:\r
+>\r
+>> I haven't looked at exactly what workarounds this enables, but if it's\r
+>> what I'm guessing (RFC 2047 escapes in the middle of RFC 2822 text\r
+>> tokens), are there really subject lines that this will misinterpret\r
+>> that weren't obviously crafted to break the workaround? \r
+>\r
+> not to get all meta, but i imagine subject lines that refer an example\r
+> of this particular issue (e.g. when talking about RFC 2047) will break\r
+> ;) I'm trying one variant here.\r
+\r
+The meta reply here, running the patch. The broken RFC 2047 got\r
+liberally accepted. :)\r
+\r
+>> The RFC 2047\r
+>> escape sequence was deliberately designed to be obscure, since RFC\r
+>> 2047 itself caused previously "standards-compliant" subject lines to\r
+>> potentially be interpreted differently.\r
+>\r
+> right, and it was designed explicitly to put the boundary markers atword\r
+> boundaries, and not in the middle of a word (i think that's what this is\r
+> all about, right?). so implementations which put the boundary markers\r
+> in the middle of a word, or which include whitespace within the encoded\r
+> text, aren't speaking RFC 2047.\r
+>\r
+> anyway, if there's a rough consensus to go forward with this, i'm not\r
+> about to block it. I understand that a large part of the business of\r
+> being an MUA is working around other people's bugs instead of expecting\r
+> them to fix them :/ I just don't like mis-rendering other text.\r
+\r
+I share your concern. Yet the amount of email with unintentionally\r
+broken encoding is much greater than the amount of email that has\r
+intentional character sequences that resemble broken encodings. Which is\r
+why I'm willing to sacrifice the latter to improve the user experience\r
+for majority of users. YMMV.\r
+\r
+BR,\r
+Jani.\r