Date: Tue, 22 Nov 2011 21:58:53 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: David Bremner <david@tethera.net>
Subject: Re: Incorrect parsing of email addresses (MIME with quotes)
Message-ID: <20111123025852.GJ9351@mit.edu>
References: <2flr522zju3.fsf@login2.uio.no>
	<4EA58DC6.6090108@fifthhorseman.net>
	<2fl1ut17iqm.fsf@diskless.uio.no> <87y5v7spk5.fsf@zancas.localnet>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87y5v7spk5.fsf@zancas.localnet>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org, Petter Reinholdtsen <pere@hungry.com>
Precedence: list

Quoth David Bremner on Nov 22 at  7:30 pm:
> On Mon, 21 Nov 2011 13:38:57 +0100, Petter Reinholdtsen <pere@hungry.com> wrote:
> > I just hope the notmuch developers can choose to follow the robustness
> > principle[1] in this case, and be liberal in what notmuch accept, and
> > conservative in what notmuch send.  After all, gnus, mutt and pine
> > handle these from fields.
> 
> It's a nice stick to beat people with, but I'm not sure it's directly
> applicable here. Notmuch is accepting the input, it just isn't
> displaying it the way you want. I guess if somebody has some patches for
> "sloppy header parsing", we can weigh the pros and cons then.
> 
> If someone wants to follow up on this, we are currently using
> 
> http://spruce.sourceforge.net/gmime/doc/gmime-gmime-utils.html#g-mime-utils-header-decode-text
> 
> There is some discussion there about dealing with bad inputs; I don't
> know if it is directly relevant.

Based on
  http://comments.gmane.org/gmane.mail.mime.gmime.devel/65
I thought gmime was supposed to be dealing with broken RFC 2047
encoding now.  Am I misinterpreting it?  Maybe a bug needs to be filed
against gmime?