linux-kernel - Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 25 Mar 2018 20:11:24 -0400
From:   Eric Sunshine <sunshine@...shineco.com>
To:     Ævar Arnfjörð Bjarmason <avarab@...il.com>
Cc:     Git List <git@...r.kernel.org>, Junio C Hamano <gitster@...ox.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default

On Sun, Mar 25, 2018 at 2:28 PM, Ævar Arnfjörð Bjarmason
<avarab@...il.com> wrote:
> The earlier change to add this option described the problem this
> option is trying to solve.
>
> This turns it on by default with a value of 1 second, which'll
> hopefully solve it, and if not user reports as well as the
> X-Mailer-Send-Delay header should help debug it.
> [...]
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@...il.com>
> ---
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> @@ -3070,7 +3070,18 @@ sendemail.smtpReloginDelay::
>  sendemail.smtpSendDelay::
>         Seconds wait in between message sending before sending another
> -       message. Set it to 0 to impose no extra delay, defaults to 0.
> +       message. Set it to 0 to impose no extra delay, defaults to 1
> +       to wait 1 second.
> ++
> +The reason for imposing a default delay is because certain popular
> +E-Mail clients such as Google's GMail completely ignore the "Date"
> +header, which format-patch is careful to set such that the patches
> +will be displayed in order, and instead sort by the time the E-mail
> +was received.

A minor point: Are you sure that it's git-format-patch that's being
careful about arranging Date: to display in the desired order, and not
git-send-email? Looking at old patches I still have hanging around
which were created with git-format-patch, I see the Date: headers are
wildly out of order, presumably because the date is taken from
Author-Date: and the patches were heavily rebased.