Date: Tue, 10 Sep 2013 18:35:53 -0400
From: Austin Clements <amdragon@MIT.EDU>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
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)
Cc: notmuch <notmuch@notmuchmail.org>
Precedence: list

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.