{"thread":{"id":"17048","subject":"[PATCH] allow 8bit data in email body sent by send-email","startedAt":"2009-01-08T13:50:57Z","lastAt":"2009-01-09T14:44:04Z","messageCount":4,"participants":["Andre Przywara","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"99701","messageId":"1231422657-15305-1-git-send-email-andre.przywara@amd.com","threadId":"17048","inReplyTo":null,"subject":"[PATCH] allow 8bit data in email body sent by send-email","fromName":"Andre Przywara","fromEmail":"andre.przywara@amd.com","sentAt":"2009-01-08T13:50:57Z","receivedAt":"2009-01-08T13:50:57Z","isPatch":true,"sender":{"key":"andre.przywara@amd.com","avatar":null},"body":"Hi,\nwhen sending patch files via git send-email, the perl script assumes\n7bit characters only. If there are other bytes in the body (foreign language\ncharacters in names or translations), some servers (like vger.kernel.org)\nreject the mail because of th�t. This patch always adds an 8bit header line\nto each mail.\nIf someone thinks this has any side-effects, tell me, I am open to suggestions.\n\nRegards,\nAndr�.\n\nSigned-off-by: Andre Przywara <andre.przywara@amd.com>\n\nAndre Przywara\nAMD-Operating System Research Center (OSRC), Dresden, Germany\nTel: +49 351 277-84917\n****to satisfy European Law for business letters:\nAdvanced Micro Devices GmbH\nKarl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen\nGeschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni\nSitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen\nRegistergericht Muenchen, HRB Nr. 43632\n\n---\n git-send-email.perl |    1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 77ca8fe..68a462c 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -793,6 +793,7 @@ To: $to${ccline}\n Subject: $subject\n Date: $date\n Message-Id: $message_id\n+Content-Transfer-Encoding: 8bit\n X-Mailer: git-send-email $gitversion\n \";\n \tif ($thread && $reply_to) {\n-- \n1.5.5\n"},{"id":"99766","messageId":"20090109072814.GA21180@coredump.intra.peff.net","threadId":"17048","inReplyTo":"1231422657-15305-1-git-send-email-andre.przywara@amd.com","subject":"Re: [PATCH] allow 8bit data in email body sent by send-email","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-09T07:28:14Z","receivedAt":"2009-01-09T07:28:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Jan 08, 2009 at 02:50:57PM +0100, Andre Przywara wrote:\n\n> when sending patch files via git send-email, the perl script assumes\n> 7bit characters only. If there are other bytes in the body (foreign language\n> characters in names or translations), some servers (like vger.kernel.org)\n> reject the mail because of th?t. This patch always adds an 8bit header line\n> to each mail.\n\nThis should be done already by git-format-patch when you generate the\npatch to feed to send-email. What exactly is the workflow you use to\ngenerate this problem? Does it matter where the non-ascii characters are\n(commit versus patch, etc)? What version of git are you using?\n\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index 77ca8fe..68a462c 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -793,6 +793,7 @@ To: $to${ccline}\n>  Subject: $subject\n>  Date: $date\n>  Message-Id: $message_id\n> +Content-Transfer-Encoding: 8bit\n>  X-Mailer: git-send-email $gitversion\n>  \";\n\nThis fix isn't right anyway. For one thing, if you're going to include\nC-T-E, you should also include a MIME-Version header. But more\nimportantly, we are already handling encoding elsewhere. So\nunconditionally adding this means that you may conflict with existing\nMIME headers in the @xh variable.\n\n-Peff\n"},{"id":"99793","messageId":"49675C38.8060208@amd.com","threadId":"17048","inReplyTo":"20090109072814.GA21180@coredump.intra.peff.net","subject":"Re: [PATCH] allow 8bit data in email body sent by send-email","fromName":"Andre Przywara","fromEmail":"andre.przywara@amd.com","sentAt":"2009-01-09T14:16:24Z","receivedAt":"2009-01-09T14:16:24Z","isPatch":true,"sender":{"key":"andre.przywara@amd.com","avatar":null},"body":"Jeff King wrote:\n>> when sending patch files via git send-email, the perl script assumes\n>> 7bit characters only. If there are other bytes in the body (foreign language\n>> characters in names or translations), some servers (like vger.kernel.org)\n>> reject the mail because of th?t. This patch always adds an 8bit header line\n>> to each mail.\n> \n> This should be done already by git-format-patch when you generate the\n> patch to feed to send-email.\nWell, this could be discussed, after all the problem lies in the actual \ntransportation, which should be the responsibility of git-send-email. \nBut I am OK with putting this into format-patch.\n > What exactly is the workflow you use to generate this problem?\nI use git format-patch to generate a patch file for a single-mail patch \n(not a patch series). Then I edit this file manually to add questions \nand comments and include my signature. During this step the umlauts came \nin. If you have a suggestion to improve this workflow, I am all ears, I \nam fairly new to git.\n> Does it matter where the non-ascii characters are\n> (commit versus patch, etc)?\nOh, right you are. If there are 8bit characters in the commit message, \ngit-format-patch adds the appropriate headers.\n > What version of git are you using?\nVersion 1.5.5 on one machine and 1.5.2.2 on another. I know, i know ;-) \nbut I haven't had time to compile a newer one, yet.\n\n> \n>> diff --git a/git-send-email.perl b/git-send-email.perl\n>> index 77ca8fe..68a462c 100755\n>> --- a/git-send-email.perl\n>> +++ b/git-send-email.perl\n>> @@ -793,6 +793,7 @@ To: $to${ccline}\n>>  Subject: $subject\n>>  Date: $date\n>>  Message-Id: $message_id\n>> +Content-Transfer-Encoding: 8bit\n>>  X-Mailer: git-send-email $gitversion\n>>  \";\n> \n> This fix isn't right anyway. For one thing, if you're going to include\n> C-T-E, you should also include a MIME-Version header. But more\n> importantly, we are already handling encoding elsewhere. So\n> unconditionally adding this means that you may conflict with existing\n> MIME headers in the @xh variable.\n\nOk, so what about adding a flag to git-format-patch that forces the 8bit \nheaders on? I think a workaround would be to add a --subject-prefix with \na special character and later remove this, but this is not really a \nlong-term solution ;-)\n\nThanks and regards,\nAndre.\n\n-- \nAndre Przywara\nAMD-Operating System Research Center (OSRC), Dresden, Germany\nTel: +49 351 277-84917\n----to satisfy European Law for business letters:\nAdvanced Micro Devices GmbH\nKarl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen\nGeschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni\nSitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen\nRegistergericht Muenchen, HRB Nr. 43632\n"},{"id":"99794","messageId":"20090109144403.GA12994@coredump.intra.peff.net","threadId":"17048","inReplyTo":"49675C38.8060208@amd.com","subject":"Re: [PATCH] allow 8bit data in email body sent by send-email","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-01-09T14:44:04Z","receivedAt":"2009-01-09T14:44:04Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 09, 2009 at 03:16:24PM +0100, Andre Przywara wrote:\n\n>> This should be done already by git-format-patch when you generate the\n>> patch to feed to send-email.\n> Well, this could be discussed, after all the problem lies in the actual  \n> transportation, which should be the responsibility of git-send-email. But \n> I am OK with putting this into format-patch.\n\nI didn't mean \"this functionality should go into format-patch\" but\nrather \"this functionality is _already_ in format-patch, and it should\nhave been triggered\".\n\nThe reason it has to be in format-patch is that only format-patch knows\nwhat the correct encoding is. It's not that useful to just say \"oh, this\nis some 8-bit data.\" You also want to give a content-type header that\nspecifies the correct encoding. And anything that contains non-ascii\ncharacters should come out of format-patch with such a header.\n\n> > What exactly is the workflow you use to generate this problem?\n> I use git format-patch to generate a patch file for a single-mail patch  \n> (not a patch series). Then I edit this file manually to add questions and \n> comments and include my signature. During this step the umlauts came in. \n> If you have a suggestion to improve this workflow, I am all ears, I am \n> fairly new to git.\n\nAh, I see. I'm not sure what the best solution is there. send-email has\nintentionally been kept pretty dumb, because implementing full MUA\nbehavior would make it pretty unwieldy. You could add an option to\nsend-email to add the 8-bit transfer-encoding header if necessary, but\nit will have to guess at (or be configured to know) the correct encoding\nof the characters.\n\nPersonally, when I want to add information like that to a patch, I pull\nthe output of format-patch into my MUA (mutt, in my case). I don't know\nif that is a workable solution for you.\n\n> Ok, so what about adding a flag to git-format-patch that forces the 8bit  \n> headers on? I think a workaround would be to add a --subject-prefix with  \n> a special character and later remove this, but this is not really a  \n> long-term solution ;-)\n\nNow that you've explained your workflow, I do think send-email is a more\nappropriate place to add a header, since format-patch never even sees\nthe data that is causing the problem. Probably the sanest thing would be\nto check each input file for non-ascii characters. If they are found,\nand the message does not already have some MIME headers, then add an\n8bit content-transfer-encoding and a text/plain content-type. In the\nlatter, you would need to specify some encoding. Most of git defaults\nto utf-8, but it should probably be configurable.\n\nWe have to do a similar thing for the --compose option, so looking at\nwhat that does is probably a good starting point.\n\n-Peff\n"}]}