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.