Re: [PATCH] send-email: Honor multi-part email messages

From: Jeff King <peff@peff.net>
Date: Jan 25, 2013, 22:24 UTC
Message-ID: <20130125222411.GD23626@sigill.intra.peff.net>
In-Reply-To: <20130125174700.GA3700@shrek.podlesie.net>

On Fri, Jan 25, 2013 at 06:47:00PM +0100, Krzysztof Mazur wrote:

Show 12 quoted lines

> On Fri, Jan 25, 2013 at 07:28:54PM +0400, Alexey Shumkin wrote:
> > "git format-patch --attach/--inline" generates multi-part messages.
> > Every part of such messages can contain non-ASCII characters with its own
> > "Content-Type" and "Content-Transfer-Encoding" headers.
> > But git-send-mail script interprets a patch-file as one-part message
> > and does not recognize multi-part messages.
> > So already quoted printable email subject may be encoded as quoted printable
> > again. Due to this bug email subject looks corrupted in email clients.
> 
> I don't think that the problem with the Subject is multi-part message
> specific. The real problem with the Subject is probably that
> is_rfc2047_quoted() does not detect that the Subject is already quoted.

I have not even looked at this problem at all, but seeing this function name:

> >  sub body_or_subject_has_nonascii {

Makes me think something is very wrong. The subject line should not have anything to do whatsoever with a content-type or content-transfer-encoding header. It should either be rfc2047 encoded or not, and the encoding used does not have to correspond to what is used elsewhere in the message. rfc2047 is very clear that other MIME headers are not necessary to interpret encoded words in headers.

So this loop:

	foreach my $f (@files) {
	        next unless (body_or_subject_has_nonascii($f)
	                     && !file_declares_8bit_cte($f));
	        $broken_encoding{$f} = 1;
	}

does not seem right at all. Only the body depends on the 8bit CTE.

-Peff