]> git.ipfire.org Git - thirdparty/git.git/commit - git-send-email.perl
send-email: automatically determine transfer-encoding
authorbrian m. carlson <sandals@crustytoothpaste.net>
Sun, 8 Jul 2018 22:17:12 +0000 (22:17 +0000)
committerJunio C Hamano <gitster@pobox.com>
Mon, 9 Jul 2018 17:55:12 +0000 (10:55 -0700)
commite67a228cd8afa7a645a321df90393deceaa57a0e
tree9ab39ce9c32007bbdbc8d96740fc3cd5c49638b2
parentf2d06fb13fc93c50067e75768a89db098a3d1809
send-email: automatically determine transfer-encoding

git send-email, when invoked without a --transfer-encoding option, sends
8bit data without a MIME version or a transfer encoding.  This has
several downsides.

First, unless the transfer encoding is specified, it defaults to 7bit,
meaning that non-ASCII data isn't allowed.  Second, if lines longer than
998 bytes are used, we will send an message that is invalid according to
RFC 5322.  The --validate option, which is the default, catches this
issue, but it isn't clear to many people how to resolve this.

To solve these issues, default the transfer encoding to "auto", so that
we explicitly specify 8bit encoding when lines don't exceed 998 bytes
and quoted-printable otherwise.  This means that we now always emit
Content-Transfer-Encoding and MIME-Version headers, so remove the
conditionals from this portion of the code.

It is unlikely that the unconditional inclusion of these two headers
will affect the deliverability of messages in anything but a positive
way, since MIME is already widespread and well understood by most email
programs.

Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-send-email.txt
git-send-email.perl
t/t9001-send-email.sh