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 21:01:32 +0000
From:   "brian m. carlson" <sandals@...stytoothpaste.net>
To:     Ævar Arnfjörð Bjarmason <avarab@...il.com>
Cc:     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 06:28:03PM +0000, Ævar Arnfjörð Bjarmason 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.
> 
> I think the trade-off of slowing down E-Mail sending to turn this on
> makes sense because:
> 
>  * GMail is a really common client, git.git's own unique authors by
>    %aE are ~30% @gmail.com, ~20% for linux.git. That's just patch
>    submitters, my guess is this it's much more common among those who
>    mostly read the list, and those users who aren't using mu4e / mutt
>    etc. anyway.
> 
>  * There's really no point in having this feature at all if it's not
>    made the default, since the entire point is to be able to read a
>    list like the git ML or the LKML and have patches from others show
>    up in order.
> 
>  * I don't think anyone's really sensitive to the sending part of
>    send-email taking longer. You just choose "all" and then switch to
>    another terminal while it does its thing if you have a huge series,
>    and for 1-3 patches I doubt anyone would notice this anyway.

I'm not sure that this is going to have the effect you want it to have.
Let me give an example to demonstrate why.

If I send a series to the list, in order for this to work, you need my
SMTP server (Postfix) to essentially send mails slowly enough to
vger.kernel.org (ZMailer) that it doesn't batch them when it sends them
to GMail.  The problem is that with my mail server, due to filtering and
such, already takes at least a second to accept, process, and relay
submitted messages.  vger still batched them and delivered them back to
me out of order.  This will be even worse with large series.

You are also assuming that my mail server will not have batched them and
delivered them out of order, which it might well do, since Postfix uses
a connection cache to machines that don't do STARTTLS (which, much to my
annoyance, vger doesn't offer).

In short, I don't think this is going to be especially helpful because
it won't change the status quo for a lot of senders.  You'd have to
insert some significant delay in order to get the effect you desire, and
even then things could still be delivered out of order.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

Download attachment "signature.asc" of type "application/pgp-signature" (868 bytes)