From: J. Bruce Fields <hidden> Date: 2016-06-15 22:43:10
On Tue, May 15, 2007 at 12:22:00AM -0400, Jeff King wrote:
Your original mail _does_ claim utf-8 for me. I wonder if Karl's mail is
getting munged by something along the path (my path is straight from vger to a
qmail server that I know is doing no munging). The headers I received, for
reference:
Hm. Yes, so if I send that patch to myself with git-send-email, I see
the same thing as you:
...
From: "J. Bruce Fields" <redacted>
To: Junio C Hamano <redacted>
Cc: git@vger.kernel.org,
Johannes Schindelin [off-list ref]
Subject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user man
ual
Date: Mon, 14 May 2007 11:21:20 -0400
Message-Id: <11791560893572-git-send-email->
X-Mailer: git-send-email 1.5.1.4.19.g69e2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
...
But the mail I got through the git list yesterday has some odd stuff in
it:
From git-owner@vger.kernel.org Mon May 14 11:22:01 2007
Received: from vger.kernel.org ([209.132.176.167])
by fieldses.org with esmtp (Exim 4.67)
(envelope-from [off-list ref])
id 1HncN6-00051C-Mh
for bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1755729AbXENPVe (ORCPT <rfc822;bfields@fieldses.org>);
Mon, 14 May 2007 11:21:34 -0400
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system did not announce
capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
message does not have MIME headers (RFC 2045-2049) to enable
encoding change, we had very little choice.
X-Warning: We ASSUME it is less harmful to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning: We don't know what character set the user used, thus we had to
write these MIME-headers with our local system default value.
MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756250AbXENPVc
(ORCPT <rfc822;git-outgoing>); Mon, 14 May 2007 11:21:32 -0400
Received: from mail.fieldses.org ([66.93.2.214]:54954 "EHLO fieldses.org"
rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
id S1755315AbXENPVb (ORCPT <rfc822;git@vger.kernel.org>);
Mon, 14 May 2007 11:21:31 -0400
Received: from bfields by fieldses.org with local (Exim 4.67)
(envelope-from [off-list ref])
id 1HncMb-0004z0-E7; Mon, 14 May 2007 11:21:29 -0400
From: "J. Bruce Fields" <redacted>
To: Junio C Hamano <redacted>
Cc: git@vger.kernel.org,
Johannes Schindelin [off-list ref]
Subject: [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
Date: Mon, 14 May 2007 11:21:20 -0400
Message-Id: <11791560893572-git-send-email->
X-Mailer: git-send-email 1.5.1.4.19.g69e2
Sender: git-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: git@vger.kernel.org
Status: RO
Any idea how that happened?
--b.
From: Jeff King <hidden> Date: 2016-06-15 22:43:10
On Tue, May 15, 2007 at 12:50:44AM -0400, J. Bruce Fields wrote:
But the mail I got through the git list yesterday has some odd stuff in
it:
From git-owner@vger.kernel.org Mon May 14 11:22:01 2007
Received: from vger.kernel.org ([209.132.176.167])
by fieldses.org with esmtp (Exim 4.67)
(envelope-from [off-list ref])
id 1HncN6-00051C-Mh
for bfields@fieldses.org; Mon, 14 May 2007 11:22:01 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
id S1755729AbXENPVe (ORCPT <rfc822;bfields@fieldses.org>);
Mon, 14 May 2007 11:21:34 -0400
X-Warning: Original message contained 8-bit characters, however during
the SMTP transport session the receiving system did not announce
capability of receiving 8-bit SMTP (RFC 1651-1653), and as this
message does not have MIME headers (RFC 2045-2049) to enable
encoding change, we had very little choice.
X-Warning: We ASSUME it is less harmful to add the MIME headers, and
convert the text to Quoted-Printable, than not to do so,
and to strip the message to 7-bits.. (RFC 1428 Appendix A)
X-Warning: We don't know what character set the user used, thus we had to
write these MIME-headers with our local system default value.
MIME-Version: 1.0
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Interesting. vger is correct in translating, since your mail server does
_not_ advertise the 8BITMIME extension (even though exim is 8-bit clean,
and could handle it).
However, the content-type is already specified, so it shouldn't need to
rewrite. However, I notice that your original message is missing a
MIME-Version: 1.0 header. My guess is that vger's logic is that without
that header, it can't trust the Content-Type you have provided (and
indeed, not including MIME-Version violates the MIME RFCs, I believe).
I assumed this was a bug in git-send-email, but looking closer, it
doesn't put in any mime information at all! So your sending smtp server
is adding in the content-type header, but it's failing to add the
MIME-Version header, which I think is a bug (I can dig up the RFC
reference if you want).
Arguably, git should be generating the full MIME header-set, since it
knows what actual encoding the message is in.
-Peff
From: Jeffrey C. Ollie <hidden> Date: 2016-06-15 22:43:10
On Tue, 2007-05-15 at 01:08 -0400, Jeff King wrote:
Interesting. vger is correct in translating, since your mail server
does
_not_ advertise the 8BITMIME extension (even though exim is 8-bit
clean,
and could handle it).
From: Jeff King <hidden> Date: 2016-06-15 22:43:10
On Tue, May 15, 2007 at 12:57:53AM -0500, Jeffrey C. Ollie wrote:
Exim can advertise the 8BITMIME extension - it's turned off by default:
Yes, although turning it on would just paper over the actual problem,
which is that vger is rewritin the content-type header with the wrong
charset. It would fix the problem for Bruce, but not for other
receivers.
The real problem is (I believe) the lack of the MIME-Version header. I
will do a few test messages momentarily (which will unfortunately
require me spamming the list a bit).
-Peff
From: Karl Hasselström <hidden> Date: 2016-06-15 22:43:10
On 2007-05-15 01:08:08 -0400, Jeff King wrote:
However, the content-type is already specified, so it shouldn't need
to rewrite. However, I notice that your original message is missing
a MIME-Version: 1.0 header. My guess is that vger's logic is that
without that header, it can't trust the Content-Type you have
provided (and indeed, not including MIME-Version violates the MIME
RFCs, I believe).
You know, this rings a bell. I've discovered that a "MIME-Version:
1.0" is needed before. :-)
"stg mail" used to have the same problem, until it was changed to use
the Python e-mail libraries for all that stuff. And since then I
haven't had problems with it.
I assumed this was a bug in git-send-email, but looking closer, it
doesn't put in any mime information at all! So your sending smtp
server is adding in the content-type header, but it's failing to add
the MIME-Version header, which I think is a bug (I can dig up the
RFC reference if you want).
Arguably, git should be generating the full MIME header-set, since
it knows what actual encoding the message is in.
I very much agree.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
From: J. Bruce Fields <hidden> Date: 2016-06-15 22:43:10
On Tue, May 15, 2007 at 01:08:08AM -0400, Jeff King wrote:
However, the content-type is already specified, so it shouldn't need to
rewrite. However, I notice that your original message is missing a
MIME-Version: 1.0 header. My guess is that vger's logic is that without
that header, it can't trust the Content-Type you have provided (and
indeed, not including MIME-Version violates the MIME RFCs, I believe).
I assumed this was a bug in git-send-email, but looking closer, it
doesn't put in any mime information at all! So your sending smtp server
is adding in the content-type header,
Nope...
but it's failing to add the
MIME-Version header, which I think is a bug (I can dig up the RFC
reference if you want).
Arguably, git should be generating the full MIME header-set, since it
knows what actual encoding the message is in.
... Yes. But actually, the Content-Type header is from
git-format-patch:
$ git format-patch --stdout 12806b^..12806b |head
From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <redacted>
Date: Thu, 10 May 2007 12:36:15 +0200
Subject: [PATCH] Add a birdview-on-the-source-code section to the user
manual
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.
So it's a git-format-patch bug?
--b.
From: Jeff King <hidden> Date: 2016-06-15 22:43:10
On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote:
... Yes. But actually, the Content-Type header is from
git-format-patch:
$ git format-patch --stdout 12806b^..12806b |head
From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <redacted>
Date: Thu, 10 May 2007 12:36:15 +0200
Subject: [PATCH] Add a birdview-on-the-source-code section to the user
manual
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Ah, interesting. I had checked that, but my test didn't produce those
headers. It seems we only produce them if there are non-ascii characters
in the commit message (and I just checked with an arbitrary commit).
So really, this (totally untested) one-liner should fix it:
Providing that nobody objects to sticking that extra header in
format-patch's output (but of course only when we actually have
non-ascii data). It's technically required if we want the output to be a
valid MIME message, but most things are unlikely to care (except vger's
apparently picky MTA).
-Peff
From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:10
Jeff King [off-list ref] writes:
quoted hunk
On Tue, May 15, 2007 at 11:24:58AM -0400, J. Bruce Fields wrote:
quoted
... Yes. But actually, the Content-Type header is from
git-format-patch:
$ git format-patch --stdout 12806b^..12806b |head
From 12806b65b0d1faec249002c51b871775dc344a47 Mon Sep 17 00:00:00 2001
From: Johannes Schindelin <redacted>
Date: Thu, 10 May 2007 12:36:15 +0200
Subject: [PATCH] Add a birdview-on-the-source-code section to the user
manual
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Ah, interesting. I had checked that, but my test didn't produce those
headers. It seems we only produce them if there are non-ascii characters
in the commit message (and I just checked with an arbitrary commit).
So really, this (totally untested) one-liner should fix it:
Providing that nobody objects to sticking that extra header in
format-patch's output (but of course only when we actually have
non-ascii data). It's technically required if we want the output to be a
valid MIME message, but most things are unlikely to care (except vger's
apparently picky MTA).
From: Jeff King <hidden> Date: 2016-06-15 22:43:10
On Tue, May 15, 2007 at 11:42:24AM -0700, Junio C Hamano wrote:
quoted
+ "MIME-Version: 1.0\n"
Thanks; I think this is a sane thing to do.
Do you want me to work up a commit message, or do you just want to
assemble it from my other discussion?
BTW, I also checked for other places where we generate a content-type.
The only other place I found was when we do multipart/mixed
(log-tree.c:209), but we correctly generate the MIME-Version header
there.
-Peff