Re: [PATCH RFC3.5.1 08/12] send-email: Simplify --compose subject sanitation

From: Jeff King <peff@peff.net>
Date: Apr 21, 2009, 02:34 UTC
Message-ID: <20090421023423.GB14479@coredump.intra.peff.net>
In-Reply-To: <1240159421-5643-1-git-send-email-mfwitten@gmail.com>

On Sun, Apr 19, 2009 at 11:43:41AM -0500, Michael Witten wrote:

Show 10 quoted lines

>  		} elsif (/^Subject:\s*(.+)\s*$/i) {
> -			$initial_subject = $1;
> -			my $subject = $initial_subject;
> -			$_ = "Subject: " .
> -				($subject =~ /[^[:ascii:]]/ ?
> -				 quote_rfc2047($subject) :
> -				 $subject) .
> -				"\n";
> +			$initial_subject = $need_8bit_cte ? quote_rfc2047($1) : $1;
> +			next;

I don't think this is a good idea. need_8bit_cte is about the _whole_ message, including all headers, and this is just about the subject. Which means that we end up rfc2047-encoding the subject unnecessarily quite a bit (since at least in git itself, most of the time the non-ascii bits are in people's names).

This makes the subject unnecessarily ugly for readers which don't do rfc2047 decoding. And while I expect that most real MUAs these days handle the decoding, it also makes life harder for people looking directly at message, or doing "grep -i ^subject: foo.mbox". Yes, I know that doesn't even remotely follow the standards (e.g., it won't handle line-wrapped headers), but I don't see any need to make it worse.

All of that being said, even if we decided that it _is_ OK to quote even when it wasn't unnecessary, your patch still isn't right. need_8bit_cte is not "does this message need an 8-bit cte at all?" but rather "does _we_ need to add an 8-bit cte?". A few lines above the ones you changed, notice that when we see the message already has a MIME-Version header, we turn set $need_8bit_cte to 0. But in that case, we still may need to encode the subject if it has non-ascii characters.

-Peff