threads / patch / 17048

patchallow 8bit data in email body sent by send-email

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

## tl;dr

4 messages between Jan 8, 2009 and Jan 9, 2009. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Andre Przywara· Jan 8, 2009, 13:50 UTC · lore

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(-)

Show changes to git-send-email.perl +1 −0

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

Jeff King· Jan 9, 2009, 07:28 UTC · re: Andre Przywara · lore

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

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

Show 5 quoted lines

> 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?

Show 11 quoted lines

> 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

Andre Przywara· Jan 9, 2009, 14:16 UTC · re: Jeff King · lore

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

Jeff King wrote:

Show 8 quoted lines

>> 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.

Show 18 quoted lines

> 
>> 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

Jeff King· Jan 9, 2009, 14:44 UTC · re: Andre Przywara · lore

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

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

Show 5 quoted lines

>> 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.

Show 6 quoted lines

> > 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