[PATCH] allow 8bit data in email body sent by send-email

[PATCH] allow 8bit data in email body sent by send-email

[Andre Przywara]

Hi,
when sending patch files via git send-email, the perl script assumes
7bit characters only. If there are other bytes in the body (foreign language
characters in names or translations), some servers (like vger.kernel.org)
reject the mail because of thät. This patch always adds an 8bit header line
to each mail.
If someone thinks this has any side-effects, tell me, I am open to suggestions.

Regards,
André.

Signed-off-by: Andre Przywara <andre.przywara@amd.com>

Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
****to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

---
 git-send-email.perl |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/git-send-email.perl b/git-send-email.perl
index 77ca8fe..68a462c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -793,6 +793,7 @@ To: $to${ccline}
 Subject: $subject
 Date: $date
 Message-Id: $message_id
+Content-Transfer-Encoding: 8bit
 X-Mailer: git-send-email $gitversion
 ";
 	if ($thread && $reply_to) {
-- 
1.5.5

Re: [PATCH] allow 8bit data in email body sent by send-email

[Jeff King]

On Thu, Jan 08, 2009 at 02:50:57PM +0100, Andre Przywara wrote:

> when sending patch files via git send-email, the perl script assumes
> 7bit characters only. If there are other bytes in the body (foreign language
> characters in names or translations), some servers (like vger.kernel.org)
> reject the mail because of th?t. This patch always adds an 8bit header line
> to each mail.

This should be done already by git-format-patch when you generate the
patch to feed to send-email. What exactly is the workflow you use to
generate this problem? Does it matter where the non-ascii characters are
(commit versus patch, etc)? What version of git are you using?

> diff --git a/git-send-email.perl b/git-send-email.perl
> index 77ca8fe..68a462c 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -793,6 +793,7 @@ To: $to${ccline}
>  Subject: $subject
>  Date: $date
>  Message-Id: $message_id
> +Content-Transfer-Encoding: 8bit
>  X-Mailer: git-send-email $gitversion
>  ";

This fix isn't right anyway. For one thing, if you're going to include
C-T-E, you should also include a MIME-Version header. But more
importantly, we are already handling encoding elsewhere. So
unconditionally adding this means that you may conflict with existing
MIME headers in the @xh variable.

-Peff

Re: [PATCH] allow 8bit data in email body sent by send-email

[Andre Przywara]

Jeff King wrote:
>> when sending patch files via git send-email, the perl script assumes
>> 7bit characters only. If there are other bytes in the body (foreign language
>> characters in names or translations), some servers (like vger.kernel.org)
>> reject the mail because of th?t. This patch always adds an 8bit header line
>> to each mail.
> 
> This should be done already by git-format-patch when you generate the
> patch to feed to send-email.
Well, this could be discussed, after all the problem lies in the actual 
transportation, which should be the responsibility of git-send-email. 
But I am OK with putting this into format-patch.
 > What exactly is the workflow you use to generate this problem?
I use git format-patch to generate a patch file for a single-mail patch 
(not a patch series). Then I edit this file manually to add questions 
and comments and include my signature. During this step the umlauts came 
in. If you have a suggestion to improve this workflow, I am all ears, I 
am fairly new to git.
> Does it matter where the non-ascii characters are
> (commit versus patch, etc)?
Oh, right you are. If there are 8bit characters in the commit message, 
git-format-patch adds the appropriate headers.
 > What version of git are you using?
Version 1.5.5 on one machine and 1.5.2.2 on another. I know, i know ;-) 
but I haven't had time to compile a newer one, yet.

> 
>> diff --git a/git-send-email.perl b/git-send-email.perl
>> index 77ca8fe..68a462c 100755
>> --- a/git-send-email.perl
>> +++ b/git-send-email.perl
>> @@ -793,6 +793,7 @@ To: $to${ccline}
>>  Subject: $subject
>>  Date: $date
>>  Message-Id: $message_id
>> +Content-Transfer-Encoding: 8bit
>>  X-Mailer: git-send-email $gitversion
>>  ";
> 
> This fix isn't right anyway. For one thing, if you're going to include
> C-T-E, you should also include a MIME-Version header. But more
> importantly, we are already handling encoding elsewhere. So
> unconditionally adding this means that you may conflict with existing
> MIME headers in the @xh variable.

Ok, so what about adding a flag to git-format-patch that forces the 8bit 
headers on? I think a workaround would be to add a --subject-prefix with 
a special character and later remove this, but this is not really a 
long-term solution ;-)

Thanks and regards,
Andre.

-- 
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632

Re: [PATCH] allow 8bit data in email body sent by send-email

[Jeff King]

On Fri, Jan 09, 2009 at 03:16:24PM +0100, Andre Przywara wrote:

>> This should be done already by git-format-patch when you generate the
>> patch to feed to send-email.
> Well, this could be discussed, after all the problem lies in the actual  
> transportation, which should be the responsibility of git-send-email. But 
> I am OK with putting this into format-patch.

I didn't mean "this functionality should go into format-patch" but
rather "this functionality is _already_ in format-patch, and it should
have been triggered".

The reason it has to be in format-patch is that only format-patch knows
what the correct encoding is. It's not that useful to just say "oh, this
is some 8-bit data." You also want to give a content-type header that
specifies the correct encoding. And anything that contains non-ascii
characters should come out of format-patch with such a header.

> > What exactly is the workflow you use to generate this problem?
> I use git format-patch to generate a patch file for a single-mail patch  
> (not a patch series). Then I edit this file manually to add questions and 
> comments and include my signature. During this step the umlauts came in. 
> If you have a suggestion to improve this workflow, I am all ears, I am 
> fairly new to git.

Ah, I see. I'm not sure what the best solution is there. send-email has
intentionally been kept pretty dumb, because implementing full MUA
behavior would make it pretty unwieldy. You could add an option to
send-email to add the 8-bit transfer-encoding header if necessary, but
it will have to guess at (or be configured to know) the correct encoding
of the characters.

Personally, when I want to add information like that to a patch, I pull
the output of format-patch into my MUA (mutt, in my case). I don't know
if that is a workable solution for you.

> Ok, so what about adding a flag to git-format-patch that forces the 8bit  
> headers on? I think a workaround would be to add a --subject-prefix with  
> a special character and later remove this, but this is not really a  
> long-term solution ;-)

Now that you've explained your workflow, I do think send-email is a more
appropriate place to add a header, since format-patch never even sees
the data that is causing the problem. Probably the sanest thing would be
to check each input file for non-ascii characters. If they are found,
and the message does not already have some MIME headers, then add an
8bit content-transfer-encoding and a text/plain content-type. In the
latter, you would need to specify some encoding. Most of git defaults
to utf-8, but it should probably be configurable.

We have to do a similar thing for the --compose option, so looking at
what that does is probably a good starting point.

-Peff