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
"brian m. carlson" <[email protected]> writes:
> 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.
> ...
> 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.
Thanks for explaining it clearly.
In the past on this list those who do not get the store-and-forward
nature of e-mail transport have brought this up a few times, but
this approach fundamentally do not work, at least for the purpose of
forcing ordering of messages at the receiving end.