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 836C5431FAF for ; Tue, 10 Sep 2013 18:51:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 1.016 X-Spam-Level: * X-Spam-Status: No, score=1.016 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=1.716, 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 kBLVBqIazSHN for ; Tue, 10 Sep 2013 18:51:49 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by olra.theworths.org (Postfix) with ESMTP id 12279431FAE for ; Tue, 10 Sep 2013 18:51:48 -0700 (PDT) X-AuditID: 1209190d-b7f078e000000937-e1-522fccb316ef Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 8C.AB.02359.3BCCF225; Tue, 10 Sep 2013 21:51:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r8B1pk6s029412; Tue, 10 Sep 2013 21:51:47 -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 r8B1phNv002816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Sep 2013 21:51:45 -0400 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80) (envelope-from ) id 1VJZao-0001Sz-Ck; Tue, 10 Sep 2013 21:51:42 -0400 From: Austin Clements To: Daniel Kahn Gillmor Subject: Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() a test In-Reply-To: <522FA24D.8080307@fifthhorseman.net> References: <1378839078-6298-1-git-send-email-jani@nikula.org> <522F73A4.90802@fifthhorseman.net> <20130910223553.GI1426@mit.edu> <522FA24D.8080307@fifthhorseman.net> User-Agent: Notmuch/0.16+37~g9701e9c (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu) Date: Tue, 10 Sep 2013 21:51:41 -0400 Message-ID: <8761u8jfbm.fsf@awakening.csail.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrLv5jH6Qweufyhat3Z+ZLK7fnMns wORxtrud1ePZqlvMAUxRXDYpqTmZZalF+nYJXBnferYyFhzkrPj2rpOpgfEWexcjJ4eEgInE gWffWSBsMYkL99azdTFycQgJ7GOUWHOnlwnC2cgoceb6JHYI5zSTxKpLd1kgnCWMEhs+7QWb xSagIbFt/3JGEFtEQF/izN0LrCA2s4CqROPai8wgtrBAusTf6X/B9nEKGErsmrQfauoyRomZ Hw+CNYgKxElc61wIVsQC1Pxr4z+wobxAx76YtZ0VwhaUODnzCQvEAi2JG/9eMk1gFJyFJDUL SWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2M4HCV5N3B+O6g0iFGAQ5G JR7eG3L6QUKsiWXFlbmHGCU5mJREeZ1PAoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8E51Asrx piRWVqUW5cOkpDlYlMR514GkBNITS1KzU1MLUotgsjIcHEoSvAdPA2UFi1LTUyvSMnNKENJM HJwgw3mAhsecARleXJCYW5yZDpE/xagoJc5rA5IQAElklObB9cLSyStGcaBXhHk9QKp4gKkI rvsV0GAmoMHffcEGlyQipKQaGAX12/KYdB22JvZY3Pa5m2tkxm0w9UrKOueYqKlhq59eSd2g NyFbYZe1QGU26/yuTBMjs2OTzyb26WdPurvptthvjcVsJxJ4S34djZ5w9uiiqXaK2w+aXpPI mfwywE1Bq+zx+pUnj196cmDT4/23ZyQKTV/cNjsqheH2eq8n39WKdZ6GzWTqOqTEUpyRaKjF XFScCABmfm7jAgMAAA== 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: Wed, 11 Sep 2013 01:51:56 -0000 On Tue, 10 Sep 2013, Daniel Kahn Gillmor wrote: > On 09/10/2013 06:35 PM, Austin Clements wrote: > >> 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? > > not to get all meta, but i imagine subject lines that refer an example > of this particular issue (e.g. when talking about RFC 2047) will break > ;) I'm trying one variant here. That's cheating. ]:--8) Though, I wonder, you mentioned in your original email that there would be subject lines that are *unrepresentable* given the worked-around RFC 2047. Did you mean that? If so, can you provide an example? Isn't it always possible to, say, RFC 2047 escape the whole subject, which would be decoded correctly whether the decoder strictly adheres to RFC 2047 or uses the workarounds? (Speaking of which, it looks like message-mode does *not* RFC 2047 encode the subject if it contains text that could be mistaken for an encoded-word, so such subjects won't get round-tripped correctly.)