On Thu, Nov 03, 2016 at 11:38:45AM -0400, Jeff King wrote:

> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
> 
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your UTF-8 bullet).
> > 
> > Try adding:
> > 
> >   Content-Transfer-Encoding: 8bit
> > 
> > I haven't seen this before, but I do recall that vger's MTA is very
> > picky about this and wants to rewrite transfer-encodings, so it seems
> > plausible.
> 
> Technically, I think you'd also need a:
> 
>   MIME-Version: 1.0
> 
> header. That being said, I just peeked at the send-email code and it
> looks like we try to add in these headers as necessary. It's possible
> there's a bug, though. What does "git send-email --dry-run" say is in
> the headers it sends out?

Answering my own question, it looks like send-email gets confused when
you give a content-type but no content-transfer-encoding. It wants to
fill in both or neither.

This probably helps:

diff --git a/git-send-email.perl b/git-send-email.perl
index da81be40c..784bb874b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1568,11 +1568,13 @@ foreach my $t (@files) {
        push @cc, recipients_cmd("cc-cmd", "cc", $cc_cmd, $t)
                if defined $cc_cmd && !$suppress_cc{'cccmd'};
 
-       if ($broken_encoding{$t} && !$has_content_type) {
+       if ($broken_encoding{$t}) {
                $xfer_encoding = '8bit' if not defined $xfer_encoding;
-               $has_content_type = 1;
-               push @xh, "Content-Type: text/plain; 
charset=$auto_8bit_encoding";
-               $body_encoding = $auto_8bit_encoding;
+               if (!$has_content_type) {
+                   $has_content_type = 1;
+                   push @xh, "Content-Type: text/plain; 
charset=$auto_8bit_encoding";
+                   $body_encoding = $auto_8bit_encoding;
+               }
        }
 
        if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {

but I think there is more cleanup to handle this case (e.g., it
auto-guesses utf-8, but it should pull the value from the existing
content-type header).

-Peff

Reply via email to