diff options
author | brian m. carlson <sandals@crustytoothpaste.net> | 2018-07-08 22:17:12 +0000 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2018-07-09 10:55:12 -0700 |
commit | e67a228cd8afa7a645a321df90393deceaa57a0e (patch) | |
tree | 9ab39ce9c32007bbdbc8d96740fc3cd5c49638b2 /Documentation/technical/shallow.txt | |
parent | send-email: accept long lines with suitable transfer encoding (diff) | |
download | tgif-e67a228cd8afa7a645a321df90393deceaa57a0e.tar.xz |
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>
Diffstat (limited to 'Documentation/technical/shallow.txt')
0 files changed, 0 insertions, 0 deletions