Thread (11 messages) 11 messages, 5 authors, 2018-08-14

Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails

From: Stefan Beller <hidden>
Date: 2018-08-14 18:39:55

On Tue, Aug 14, 2018 at 11:15 AM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:
Add a --send-delay option with a corresponding sendemail.smtpSendDelay
configuration variable. When set to e.g. 2, this causes send-email to
sleep 2 seconds before sending the next E-Mail. We'll only sleep
between sends, not before the first send, or after the last.

This option has two uses. Firstly, to be able to Ctrl+C a long send
with "all" if you have a change of heart. Secondly, as a hack in some
mail setups to, with a sufficiently high delay, force the receiving
client to sort the E-Mails correctly.

Some popular E-Mail clients 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.

Google's GMail is a good example of such a client. It ostensibly sorts
by some approximation of received time (although not by any "Received"
header). It's more usual than not to see patches showing out of order
in GMail. To take a few examples of orders seen on patches on the Git
mailing list:

    1 -> 3 -> 4 -> 2 -> 8 -> 7 (completion by Nguyễn Thái Ngọc Duy)
    2 -> 0 -> 1 -> 3 (pack search by Derrick Stolee)
    3 -> 2 -> 1 (fast-import by Jameson Miller)
    2 -> 3 -> 1 -> 5 -> 4 -> 6 (diff-highlight by Jeff King)

The reason to add the new "X-Mailer-Send-Delay" header is to make it
easy to tell what the imposed delay was, if any. This allows for
gathering some data on how the transfer of E-Mails with & without this
option behaves. This may not be workable without really long delays,
see [1] and [2].

The reason for why the getopt format is "send-delay=s" instead of
"send-delay=d" is because we're doing manual validation of the value
we get passed, which getopt would corrupt in cases of e.g. float
values before we could show a sensible error message.

1. https://public-inbox.org/git/20180325210132.GE74743@genre.crustytoothpaste.net/
2. https://public-inbox.org/git/xmqqpo3rehe4.fsf@gitster-ct.c.googlers.com/

Signed-off-by: Ævar Arnfjörð Bjarmason <redacted>
---

I submitted this back in March hoping it would solve mail ordering
problems, but the other motive I had for this is that I'm paranoid
that I'm sending out bad E-Mails, and tend to "y" to each one because
"a" is too fast.'
Heh. GMail seems to have added an Undo button in their UI, which
would be the same feature as this one. (Hit Ctrl+C in time to "undo"
the sending command)

I have been bitten quite a few times by using "a" as I had old
series still laying around, such that it would send a new series and parts
of the old series (or when you changed subjects and resend another
iteration of a series, you may end up with two "patch 1"s).
So I learned to be careful before pressing "a" on sending.

Maybe the underlying issue is that you really only want to send a series
and not "all" as send-email asks for.
So maybe that dialog could learn a [s]eries switch, which would
check either filenames to count up, or if the base that is recorded
(base-commit for first and prerequisite-patch-id for followups)
is consistent.

    Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll|[s]eries):

Another note:
I personally never use no/quit, but Ctrl+C for both cases.

This is also different than the feature of 5453b83bdf9 (send-email
--batch-size to work around some SMTP server limit, 2017-05-21)
which introduced sendemail.smtpReloginDelay, which would offer the
same functionality when the batch-size is set to 1. (Although this would
keep you connected to the server as well as add the X-Mailer-Send-Delay
header, which is nothing from the official email RFC, but your own invention?)

Having sorted mails in GMail would be nice!

Thanks,
Stefan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help