From: Jani Nikula Date: Wed, 11 Sep 2013 18:21:34 +0000 (+0300) Subject: Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() a test X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=1b9e1d4708206dc2658496f4985bd3835ed56f10;p=notmuch-archives.git Re: [PATCH] lib/cli: pass GMIME_ENABLE_RFC2047_WORKAROUNDS to g_mime_init() a test --- diff --git a/25/6e6a52b9f94c8b9ef2a9f9ffefd1d0d32f70a2 b/25/6e6a52b9f94c8b9ef2a9f9ffefd1d0d32f70a2 new file mode 100644 index 000000000..60d212153 --- /dev/null +++ b/25/6e6a52b9f94c8b9ef2a9f9ffefd1d0d32f70a2 @@ -0,0 +1,112 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 180CF431FAF + for ; Wed, 11 Sep 2013 11:21:43 -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 5je5qsJttItT for ; + Wed, 11 Sep 2013 11:21:35 -0700 (PDT) +Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com + [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client + certificate requested) by olra.theworths.org (Postfix) with ESMTPS id + 29244431FAE for ; Wed, 11 Sep 2013 11:21:35 -0700 + (PDT) +Received: by mail-wg0-f54.google.com with SMTP id e11so7011036wgh.21 + for ; Wed, 11 Sep 2013 11:21:34 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:from:to:cc:subject:in-reply-to:references + :user-agent:date:message-id:mime-version:content-type; + bh=oEJ5P9HRMlMMSWpyxKWcVX6iHJq78WfkDonNgh2SLVo=; + b=czZrm9YWXPPV0Hadp2//32pi0qshN8UfCSSMKWyVwFWY+ojoy4eJcnmbJRnXUsP9XL + 27BkoWojfbTIEy7G6LXxovzQ2etU1sH9BHfnj+frF0opaR+RELXbqKiiA0RMzLFuN6lm + aWbOomJ26qwRzrkNV78JCVpMxWgz1jVu2B32tGZYRsy/rb10YlQNh2IoWn9uIldmmvA1 + sdGIjFj/xnq0v9ri6es1FhbEOfnEZIr3tm5E3y9swd/ziYDM64AtdCt4R8MKcAYvMLax + pyngTCLLFnl5EwcI6MZzL1Pm38t5JdKqYQp7RJPzAWsMcZbfw0UAbREUga48L8La81l2 + vNsw== +X-Gm-Message-State: + ALoCoQkax4J2NXG1bSye2bEZat0e2fcDklKbjFU2mvkkOSGW/WNunjNO7rmxYnRFVGtSn6DGidqM +X-Received: by 10.180.38.73 with SMTP id e9mr2470388wik.31.1378923694059; + Wed, 11 Sep 2013 11:21:34 -0700 (PDT) +Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi. + [88.195.111.91]) + by mx.google.com with ESMTPSA id ey2sm12457863wib.5.1969.12.31.16.00.00 + (version=TLSv1.2 cipher=RC4-SHA bits=128/128); + Wed, 11 Sep 2013 11:21:33 -0700 (PDT) +From: Jani Nikula +To: Daniel Kahn Gillmor , + Austin Clements +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+75~g1a51174 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-pc-linux-gnu) +Date: Wed, 11 Sep 2013 21:21:34 +0300 +Message-ID: <87ob7zp6c1.fsf@nikula.org> +MIME-Version: 1.0 +Content-Type: text/plain +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 18:21:43 -0000 + +On Wed, 11 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. + +The meta reply here, running the patch. The broken RFC 2047 got +liberally accepted. :) + +>> 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. +> +> right, and it was designed explicitly to put the boundary markers atword +> boundaries, and not in the middle of a word (i think that's what this is +> all about, right?). so implementations which put the boundary markers +> in the middle of a word, or which include whitespace within the encoded +> text, aren't speaking RFC 2047. +> +> anyway, if there's a rough consensus to go forward with this, i'm not +> about to block it. I understand that a large part of the business of +> being an MUA is working around other people's bugs instead of expecting +> them to fix them :/ I just don't like mis-rendering other text. + +I share your concern. Yet the amount of email with unintentionally +broken encoding is much greater than the amount of email that has +intentional character sequences that resemble broken encodings. Which is +why I'm willing to sacrifice the latter to improve the user experience +for majority of users. YMMV. + +BR, +Jani.