{"thread":{"id":"48142","subject":"[PATCH 0/2] send-email: impose a delay while sending to appease GMail","startedAt":"2018-03-25T18:28:45Z","lastAt":"2018-08-14T21:02:50Z","messageCount":14,"participants":["Ævar Arnfjörð Bjarmason","brian m. carlson","Eric Sunshine","Junio C Hamano","Eric Wong","Stefan Beller"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"342918","messageId":"20180325182803.30036-1-avarab@gmail.com","threadId":"48142","inReplyTo":null,"subject":"[PATCH 0/2] send-email: impose a delay while sending to appease GMail","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-03-25T18:28:01Z","receivedAt":"2018-03-25T18:28:45Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"GMail doesn't sort E-Mail by the \"Date\" header, but by when the E-Mail\nwas received. As a result patches sent to the git ML and LKML (and\nfriends) show up out of order in GMail.\n\nThis series works around that issue by sleeping for 1 second between\nsending E-Mails.\n\nIf you're on the LKML and wondering why you got this, I figured\nfeedback from the other big user (that I know of) of send-email would\nbe helpful.\n\nÆvar Arnfjörð Bjarmason (2):\n  send-email: add an option to impose delay sent E-Mails\n  send-email: supply a --send-delay=1 by default\n\n Documentation/config.txt         | 17 ++++++++++\n Documentation/git-send-email.txt |  4 +++\n git-send-email.perl              | 15 +++++++--\n t/t9001-send-email.sh            | 55 ++++++++++++++++++++++++++++++++\n 4 files changed, 89 insertions(+), 2 deletions(-)\n\n-- \n2.16.2.804.g6dcf76e118\n\n"},{"id":"342919","messageId":"20180325182803.30036-3-avarab@gmail.com","threadId":"48142","inReplyTo":"20180325182803.30036-1-avarab@gmail.com","subject":"[PATCH 2/2] send-email: supply a --send-delay=1 by default","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-03-25T18:28:03Z","receivedAt":"2018-03-25T18:28:47Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"The earlier change to add this option described the problem this\noption is trying to solve.\n\nThis turns it on by default with a value of 1 second, which'll\nhopefully solve it, and if not user reports as well as the\nX-Mailer-Send-Delay header should help debug it.\n\nI think the trade-off of slowing down E-Mail sending to turn this on\nmakes sense because:\n\n * GMail is a really common client, git.git's own unique authors by\n   %aE are ~30% @gmail.com, ~20% for linux.git. That's just patch\n   submitters, my guess is this it's much more common among those who\n   mostly read the list, and those users who aren't using mu4e / mutt\n   etc. anyway.\n\n * There's really no point in having this feature at all if it's not\n   made the default, since the entire point is to be able to read a\n   list like the git ML or the LKML and have patches from others show\n   up in order.\n\n * I don't think anyone's really sensitive to the sending part of\n   send-email taking longer. You just choose \"all\" and then switch to\n   another terminal while it does its thing if you have a huge series,\n   and for 1-3 patches I doubt anyone would notice this anyway.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n Documentation/config.txt | 13 ++++++++++++-\n git-send-email.perl      |  1 +\n t/t9001-send-email.sh    |  4 ++--\n 3 files changed, 15 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex f155d349c0..bd578642c1 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -3070,7 +3070,18 @@ sendemail.smtpReloginDelay::\n \n sendemail.smtpSendDelay::\n \tSeconds wait in between message sending before sending another\n-\tmessage. Set it to 0 to impose no extra delay, defaults to 0.\n+\tmessage. Set it to 0 to impose no extra delay, defaults to 1\n+\tto wait 1 second.\n++\n+The reason for imposing a default delay is because certain popular\n+E-Mail clients such as Google's GMail completely ignore the \"Date\"\n+header, which format-patch is careful to set such that the patches\n+will be displayed in order, and instead sort by the time the E-mail\n+was received.\n++\n+This causes sent E-Mail to be shown completely out of order in such\n+clients, imposing the delay is a workaround that should usually work\n+(although it's by no means guaranteed).\n +\n See also the `--send-delay` option of linkgit:git-send-email[1].\n \ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 013277ede2..ddbc44f1c9 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -489,6 +489,7 @@ die sprintf(__(\"Unknown --confirm setting: '%s'\\n\"), $confirm)\n \tunless $confirm =~ /^(?:auto|cc|compose|always|never)/;\n die sprintf(__(\"Invalid --send-delay setting: '%s'\\n\"), $send_delay)\n \tif defined $send_delay and $send_delay !~ /^[0-9]+$/s;\n+$send_delay = 1 unless defined $send_delay;\n \n # Debugging, print out the suppressions.\n if (0) {\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex fafa61c5d6..1580e00fce 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -1713,7 +1713,7 @@ test_expect_success '--send-delay expects whole non-negative seconds' '\n \ttest_i18ngrep \"Invalid --send-delay setting\" errors\n '\n \n-test_expect_success $PREREQ \"there is no default --send-delay\" '\n+test_expect_success $PREREQ \"there is a default --send-delay\" '\n \tclean_fake_sendmail &&\n \trm -fr outdir &&\n \tgit format-patch -3 -o outdir &&\n@@ -1724,7 +1724,7 @@ test_expect_success $PREREQ \"there is no default --send-delay\" '\n \t\toutdir/*.patch \\\n \t\t2>stderr >stdout &&\n \ttest $(grep -c \"X-Mailer:\" stdout) = 3 &&\n-\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 0\n+\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 2\n '\n \n test_expect_success $PREREQ '--send-delay adds a X-Mailer-Send-Delay header to affected E-Mails' '\n-- \n2.16.2.804.g6dcf76e118\n\n"},{"id":"342920","messageId":"20180325182803.30036-2-avarab@gmail.com","threadId":"48142","inReplyTo":"20180325182803.30036-1-avarab@gmail.com","subject":"[PATCH 1/2] send-email: add an option to impose delay sent E-Mails","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-03-25T18:28:02Z","receivedAt":"2018-03-25T18:29:03Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Add a --send-delay option with a corresponding sendemail.smtpSendDelay\nconfiguration variable. When set to e.g. 2, this causes send-email to\nsleep 2 seconds before sending the next E-Mail. We'll only sleep\nbetween sends, not before the first send, or after the last.\n\nThis option is useful because certain popular E-Mail clients\ncompletely ignore the \"Date\" header, which format-patch is careful to\nset such that the patches will be displayed in order, and instead sort\nby the time the E-mail was received.\n\nGoogle's GMail is a good example of such a client. It ostensibly sorts\nby some approximation of received time (although not by any \"Received\"\nheader). It's more usual than not to see patches showing out of order\nin GMail. To take a few examples of orders seen on recent patches on\nthe Git mailing list:\n\n    1 -> 3 -> 4 -> 2 -> 8 -> 7 (completion by Nguyễn Thái Ngọc Duy)\n    2 -> 0 -> 1 -> 3 (pack search by Derrick Stolee)\n    3 -> 2 -> 1 (fast-import by Jameson Miller)\n    2 -> 3 -> 1 -> 5 -> 4 -> 6 (diff-highlight by Jeff King)\n\nMy own patches to Git are always in order because this bothers me\nenough that I never use the \"all\" option to send-email, instead I wait\na second and manually type \"y\" for each one, so I have years of\nanecdotal data showing that this works with GMail. This new option\nwill allow me to set a config to do what I've been doing manually.\n\nI've also noticed that E-Mail from some other contributors tends to be\nin order, e.g. Michael Haggerty's usually are. When I asked him about\nhe just uses the \"all\" option, but digging further revealed that the\ndetails of his mail routing were imposing a similar delay, so his\nmails similarly arrived at Google with some delay.\n\nThe reason to add the new \"X-Mailer-Send-Delay\" header is to make it\neasy to tell what the imposed delay was, if any. A subsequent change\nwill seek to make this option the default, being able to see from the\nheaders how long the sleep was.\n\nThe reason for why the getopt format is \"send-delay=s\" instead of\n\"send-delay=d\" is because we're doing manual validation of the value\nwe get passed, which getopt would corrupt in cases of e.g. float\nvalues before we could show a sensible error message.\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n Documentation/config.txt         |  6 ++++\n Documentation/git-send-email.txt |  4 +++\n git-send-email.perl              | 14 ++++++--\n t/t9001-send-email.sh            | 55 ++++++++++++++++++++++++++++++++\n 4 files changed, 77 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex ce9102cea8..f155d349c0 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -3068,6 +3068,12 @@ sendemail.smtpReloginDelay::\n \tSeconds wait before reconnecting to smtp server.\n \tSee also the `--relogin-delay` option of linkgit:git-send-email[1].\n \n+sendemail.smtpSendDelay::\n+\tSeconds wait in between message sending before sending another\n+\tmessage. Set it to 0 to impose no extra delay, defaults to 0.\n++\n+See also the `--send-delay` option of linkgit:git-send-email[1].\n+\n showbranch.default::\n \tThe default set of branches for linkgit:git-show-branch[1].\n \tSee linkgit:git-show-branch[1].\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 71ef97ba9b..169ad78a2b 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -268,6 +268,10 @@ must be used for each option.\n \twith --batch-size option.  Defaults to the `sendemail.smtpReloginDelay`\n \tconfiguration variable.\n \n+--send-delay=<int>::\n+\tWait $<int> between sending emails. Defaults to the\n+\t`sendemail.smtpSendDelay` configuration variable.\n+\n Automating\n ~~~~~~~~~~\n \ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 2fa7818ca9..013277ede2 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -89,6 +89,7 @@ git send-email --dump-aliases\n     --batch-size            <int>  * send max <int> message per connection.\n     --relogin-delay         <int>  * delay <int> seconds between two successive login.\n                                      This option can only be used with --batch-size\n+    --send-delay            <int>  * ensure that <int> seconds pass between two successive sends.\n \n   Automating:\n     --identity              <str>  * Use the sendemail.<id> options.\n@@ -225,7 +226,7 @@ my ($cover_cc, $cover_to);\n my ($to_cmd, $cc_cmd);\n my ($smtp_server, $smtp_server_port, @smtp_server_options);\n my ($smtp_authuser, $smtp_encryption, $smtp_ssl_cert_path);\n-my ($batch_size, $relogin_delay);\n+my ($batch_size, $relogin_delay, $send_delay);\n my ($identity, $aliasfiletype, @alias_files, $smtp_domain, $smtp_auth);\n my ($validate, $confirm);\n my (@suppress_cc);\n@@ -259,6 +260,7 @@ my %config_settings = (\n     \"smtpauth\" => \\$smtp_auth,\n     \"smtpbatchsize\" => \\$batch_size,\n     \"smtprelogindelay\" => \\$relogin_delay,\n+    \"smtpsenddelay\" => \\$send_delay,\n     \"to\" => \\@initial_to,\n     \"tocmd\" => \\$to_cmd,\n     \"cc\" => \\@initial_cc,\n@@ -373,6 +375,7 @@ $rc = GetOptions(\n \t\t    \"no-xmailer\" => sub {$use_xmailer = 0},\n \t\t    \"batch-size=i\" => \\$batch_size,\n \t\t    \"relogin-delay=i\" => \\$relogin_delay,\n+\t\t    \"send-delay=s\" => \\$send_delay,\n \t );\n \n usage() if $help;\n@@ -484,6 +487,8 @@ if ($confirm_unconfigured) {\n };\n die sprintf(__(\"Unknown --confirm setting: '%s'\\n\"), $confirm)\n \tunless $confirm =~ /^(?:auto|cc|compose|always|never)/;\n+die sprintf(__(\"Invalid --send-delay setting: '%s'\\n\"), $send_delay)\n+\tif defined $send_delay and $send_delay !~ /^[0-9]+$/s;\n \n # Debugging, print out the suppressions.\n if (0) {\n@@ -1552,7 +1557,8 @@ $references = $initial_in_reply_to || '';\n $subject = $initial_subject;\n $message_num = 0;\n \n-foreach my $t (@files) {\n+foreach my $i (0 .. $#files) {\n+\tmy $t = $files[$i];\n \topen my $fh, \"<\", $t or die sprintf(__(\"can't open file %s\"), $t);\n \n \tmy $author = undef;\n@@ -1732,6 +1738,10 @@ foreach my $t (@files) {\n \tif (defined $xfer_encoding or $has_content_type) {\n \t\tunshift @xh, 'MIME-Version: 1.0' unless $has_mime_version;\n \t}\n+\tif ($send_delay && $i > 0) {\n+\t\tpush @xh, \"X-Mailer-Send-Delay: $send_delay\";\n+\t\tsleep $send_delay;\n+\t}\n \n \t$needs_confirm = (\n \t\t$confirm eq \"always\" or\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex e80eacbb1b..fafa61c5d6 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -1702,6 +1702,61 @@ test_expect_success '--dump-aliases must be used alone' '\n \ttest_must_fail git send-email --dump-aliases --to=janice@example.com -1 refs/heads/accounting\n '\n \n+test_expect_success '--send-delay expects whole non-negative seconds' '\n+\ttest_must_fail git send-email --send-delay=-1 HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors &&\n+\ttest_must_fail git send-email --send-delay=1.5 HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors &&\n+\ttest_must_fail git -c sendemail.smtpSendDelay=-1 send-email HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors &&\n+\ttest_must_fail git -c sendemail.smtpSendDelay=1.5 send-email HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors\n+'\n+\n+test_expect_success $PREREQ \"there is no default --send-delay\" '\n+\tclean_fake_sendmail &&\n+\trm -fr outdir &&\n+\tgit format-patch -3 -o outdir &&\n+\tgit send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\toutdir/*.patch \\\n+\t\t2>stderr >stdout &&\n+\ttest $(grep -c \"X-Mailer:\" stdout) = 3 &&\n+\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 0\n+'\n+\n+test_expect_success $PREREQ '--send-delay adds a X-Mailer-Send-Delay header to affected E-Mails' '\n+\tclean_fake_sendmail &&\n+\trm -fr outdir &&\n+\tgit format-patch -3 -o outdir &&\n+\tgit send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t--send-delay=2 \\\n+\t\toutdir/*.patch \\\n+\t\t2>stderr >stdout &&\n+\ttest $(grep -c \"X-Mailer:\" stdout) = 3 &&\n+\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 2\n+'\n+\n+test_expect_success $PREREQ '--send-delay=0 disables any imposed delay on E-Mail sending' '\n+\tclean_fake_sendmail &&\n+\trm -fr outdir &&\n+\tgit format-patch -3 -o outdir &&\n+\tgit -c sendemail.smtpSendDelay=3 send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t--send-delay=0 \\\n+\t\toutdir/*.patch \\\n+\t\t2>stderr >stdout &&\n+\ttest $(grep -c \"X-Mailer:\" stdout) = 3 &&\n+\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 0\n+'\n+\n test_sendmail_aliases () {\n \tmsg=\"$1\" && shift &&\n \texpect=\"$@\" &&\n-- \n2.16.2.804.g6dcf76e118\n\n"},{"id":"342944","messageId":"20180325210132.GE74743@genre.crustytoothpaste.net","threadId":"48142","inReplyTo":"20180325182803.30036-3-avarab@gmail.com","subject":"Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-03-25T21:01:32Z","receivedAt":"2018-03-25T21:01:44Z","isPatch":true,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Sun, Mar 25, 2018 at 06:28:03PM +0000, Ævar Arnfjörð Bjarmason wrote:\n> The earlier change to add this option described the problem this\n> option is trying to solve.\n> \n> This turns it on by default with a value of 1 second, which'll\n> hopefully solve it, and if not user reports as well as the\n> X-Mailer-Send-Delay header should help debug it.\n> \n> I think the trade-off of slowing down E-Mail sending to turn this on\n> makes sense because:\n> \n>  * GMail is a really common client, git.git's own unique authors by\n>    %aE are ~30% @gmail.com, ~20% for linux.git. That's just patch\n>    submitters, my guess is this it's much more common among those who\n>    mostly read the list, and those users who aren't using mu4e / mutt\n>    etc. anyway.\n> \n>  * There's really no point in having this feature at all if it's not\n>    made the default, since the entire point is to be able to read a\n>    list like the git ML or the LKML and have patches from others show\n>    up in order.\n> \n>  * I don't think anyone's really sensitive to the sending part of\n>    send-email taking longer. You just choose \"all\" and then switch to\n>    another terminal while it does its thing if you have a huge series,\n>    and for 1-3 patches I doubt anyone would notice this anyway.\n\nI'm not sure that this is going to have the effect you want it to have.\nLet me give an example to demonstrate why.\n\nIf I send a series to the list, in order for this to work, you need my\nSMTP server (Postfix) to essentially send mails slowly enough to\nvger.kernel.org (ZMailer) that it doesn't batch them when it sends them\nto GMail.  The problem is that with my mail server, due to filtering and\nsuch, already takes at least a second to accept, process, and relay\nsubmitted messages.  vger still batched them and delivered them back to\nme out of order.  This will be even worse with large series.\n\nYou are also assuming that my mail server will not have batched them and\ndelivered them out of order, which it might well do, since Postfix uses\na connection cache to machines that don't do STARTTLS (which, much to my\nannoyance, vger doesn't offer).\n\nIn short, I don't think this is going to be especially helpful because\nit won't change the status quo for a lot of senders.  You'd have to\ninsert some significant delay in order to get the effect you desire, and\neven then things could still be delivered out of order.\n-- \nbrian m. carlson / brian with sandals: Houston, Texas, US\nhttps://www.crustytoothpaste.net/~bmc | My opinion only\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"342947","messageId":"87605jyfvi.fsf@evledraar.gmail.com","threadId":"48142","inReplyTo":"20180325210132.GE74743@genre.crustytoothpaste.net","subject":"Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-03-25T22:01:05Z","receivedAt":"2018-03-25T22:01:13Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sun, Mar 25 2018, brian m. carlson wrote:\n\n> On Sun, Mar 25, 2018 at 06:28:03PM +0000, Ævar Arnfjörð Bjarmason wrote:\n>> The earlier change to add this option described the problem this\n>> option is trying to solve.\n>>\n>> This turns it on by default with a value of 1 second, which'll\n>> hopefully solve it, and if not user reports as well as the\n>> X-Mailer-Send-Delay header should help debug it.\n>>\n>> I think the trade-off of slowing down E-Mail sending to turn this on\n>> makes sense because:\n>>\n>>  * GMail is a really common client, git.git's own unique authors by\n>>    %aE are ~30% @gmail.com, ~20% for linux.git. That's just patch\n>>    submitters, my guess is this it's much more common among those who\n>>    mostly read the list, and those users who aren't using mu4e / mutt\n>>    etc. anyway.\n>>\n>>  * There's really no point in having this feature at all if it's not\n>>    made the default, since the entire point is to be able to read a\n>>    list like the git ML or the LKML and have patches from others show\n>>    up in order.\n>>\n>>  * I don't think anyone's really sensitive to the sending part of\n>>    send-email taking longer. You just choose \"all\" and then switch to\n>>    another terminal while it does its thing if you have a huge series,\n>>    and for 1-3 patches I doubt anyone would notice this anyway.\n>\n> I'm not sure that this is going to have the effect you want it to have.\n> Let me give an example to demonstrate why.\n>\n> If I send a series to the list, in order for this to work, you need my\n> SMTP server (Postfix) to essentially send mails slowly enough to\n> vger.kernel.org (ZMailer) that it doesn't batch them when it sends them\n> to GMail.  The problem is that with my mail server, due to filtering and\n> such, already takes at least a second to accept, process, and relay\n> submitted messages.  vger still batched them and delivered them back to\n> me out of order.  This will be even worse with large series.\n>\n> You are also assuming that my mail server will not have batched them and\n> delivered them out of order, which it might well do, since Postfix uses\n> a connection cache to machines that don't do STARTTLS (which, much to my\n> annoyance, vger doesn't offer).\n>\n> In short, I don't think this is going to be especially helpful because\n> it won't change the status quo for a lot of senders.  You'd have to\n> insert some significant delay in order to get the effect you desire, and\n> even then things could still be delivered out of order.\n\nGood point. I also see that (via git log --author=Ævar --grep='^\\[PATCH\n') that this series itself arrived out of order (0 -> 2 -> 1), but I\ndon't know to what extent public-inbox itself might be batching things.\n\nIt would be interesting to get reports from other GMail users as to what\norder these mails were shown in, but I think as soon as they're replied\nto that info's gone, at least for 2/2, which is the potentially out of\norder one in this case.\n\nIn general I realize that this won't be a general solution that'll work\nin all cases. E.g. I have a local SMTP on my laptop, if I'm on a plane\nit wouldn't matter if the delay was 2 hours, it would be batched up\nlocally and sent all at once.\n\nI was hoping we could find some sweet spot where the systems along the\nway (common smtpd's, majordomo, public-inbox's git repo) would as a\nresult get this right most of the time for the purposes of appeasing\nthis really common mail client, but maybe that's not going to work out.\n"},{"id":"342949","messageId":"CAPig+cQ6EK=Q00panZECVvWt3pJyS9acC1n4mgogMmk5J4hO8g@mail.gmail.com","threadId":"48142","inReplyTo":"20180325182803.30036-3-avarab@gmail.com","subject":"Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2018-03-26T00:11:24Z","receivedAt":"2018-03-26T00:11:52Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Mar 25, 2018 at 2:28 PM, Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n> The earlier change to add this option described the problem this\n> option is trying to solve.\n>\n> This turns it on by default with a value of 1 second, which'll\n> hopefully solve it, and if not user reports as well as the\n> X-Mailer-Send-Delay header should help debug it.\n> [...]\n> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n> ---\n> diff --git a/Documentation/config.txt b/Documentation/config.txt\n> @@ -3070,7 +3070,18 @@ sendemail.smtpReloginDelay::\n>  sendemail.smtpSendDelay::\n>         Seconds wait in between message sending before sending another\n> -       message. Set it to 0 to impose no extra delay, defaults to 0.\n> +       message. Set it to 0 to impose no extra delay, defaults to 1\n> +       to wait 1 second.\n> ++\n> +The reason for imposing a default delay is because certain popular\n> +E-Mail clients such as Google's GMail completely ignore the \"Date\"\n> +header, which format-patch is careful to set such that the patches\n> +will be displayed in order, and instead sort by the time the E-mail\n> +was received.\n\nA minor point: Are you sure that it's git-format-patch that's being\ncareful about arranging Date: to display in the desired order, and not\ngit-send-email? Looking at old patches I still have hanging around\nwhich were created with git-format-patch, I see the Date: headers are\nwildly out of order, presumably because the date is taken from\nAuthor-Date: and the patches were heavily rebased.\n"},{"id":"342957","messageId":"xmqqpo3rehe4.fsf@gitster-ct.c.googlers.com","threadId":"48142","inReplyTo":"20180325210132.GE74743@genre.crustytoothpaste.net","subject":"Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-26T01:48:35Z","receivedAt":"2018-03-26T01:48:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n> I'm not sure that this is going to have the effect you want it to have.\n> Let me give an example to demonstrate why.\n> ...\n> In short, I don't think this is going to be especially helpful because\n> it won't change the status quo for a lot of senders.  You'd have to\n> insert some significant delay in order to get the effect you desire, and\n> even then things could still be delivered out of order.\n\nThanks for explaining it clearly.\n\nIn the past on this list those who do not get the store-and-forward\nnature of e-mail transport have brought this up a few times, but\nthis approach fundamentally do not work, at least for the purpose of\nforcing ordering of messages at the receiving end.\n\n"},{"id":"342958","messageId":"xmqqlgefeh1c.fsf@gitster-ct.c.googlers.com","threadId":"48142","inReplyTo":"CAPig+cQ6EK=Q00panZECVvWt3pJyS9acC1n4mgogMmk5J4hO8g@mail.gmail.com","subject":"Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-03-26T01:56:15Z","receivedAt":"2018-03-26T01:56:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine <sunshine@sunshineco.com> writes:\n\n> A minor point: Are you sure that it's git-format-patch that's being\n> careful about arranging Date: to display in the desired order, and not\n> git-send-email? Looking at old patches I still have hanging around\n> which were created with git-format-patch, I see the Date: headers are\n> wildly out of order, presumably because the date is taken from\n> Author-Date: and the patches were heavily rebased.\n\nsend-email uses the current time as the timestamp it lets MTA to see\n(and for a N-patch series, the first patch gets current time minus\nN, and later patches get newer timestamps with 1 second increment).\n\nThe Date: field in the input file to the command has nothing to\nparticipate in this process; sending a series that has patches that\nhave been shuffled with \"rebase -i\" would still give older timestamp\nto the earlier message while sending the series out.\n\nThat is sufficient for any MUA that is capable of sorting the\nmessages in the sender's timestamp order; even though there is no\nway to force the actual order in which an MTA on the receiving end\nsees the messages, it is not necessary and it would not help X-<.\n"},{"id":"343200","messageId":"20180328012637.GA12551@whir","threadId":"48142","inReplyTo":"87605jyfvi.fsf@evledraar.gmail.com","subject":"Re: [PATCH 2/2] send-email: supply a --send-delay=1 by default","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2018-03-28T01:26:37Z","receivedAt":"2018-03-28T01:26:46Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> Good point. I also see that (via git log --author=Ævar --grep='^\\[PATCH\n> ') that this series itself arrived out of order (0 -> 2 -> 1), but I\n> don't know to what extent public-inbox itself might be batching things.\n\npublic-inbox doesn't batch, aside from when the\npublic-inbox-watch process gets restarted and needs to catch up\nusing readdir.  Once it's done catching up with readdir, it\ngets into an inotify loop which injects messages in the order\nthe MTA (or offlineimap) puts them in a Maildir.\n\nRight now, public-inbox only sorts by Date: header in the mail.\n\nThe next Xapian schema revision of public-inbox will use\ninternally sorts search results(*) by the date in the newest\nReceived: header.  That is analogous to git committer date.  The\ndisplayed message date will still be sorted by the Date: header\n(analogous to git author date); since git-send-email already\nalters the Date: in a series for sorting.\n\nThis allow messages/threads which are actually new get bumped to\nthe top of the homepage; regardless of how wrong the original\nsender's clock was.\n\nIt should help prevent kernel developers from crafting message\ndates with optimization for classic^Wextra reviews in mind :)\n\n\n(*) all the look-at-a-bunch-of-messages operations, including\n    the landing page (e.g. https://public-inbox.org/git/)\n    is a Xapian search query, nowadays; but \"git log\"\n"},{"id":"355577","messageId":"20180814181534.21234-1-avarab@gmail.com","threadId":"48142","inReplyTo":"20180325182803.30036-1-avarab@gmail.com","subject":"[PATCH v2] send-email: add an option to impose delay sent E-Mails","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-14T18:15:34Z","receivedAt":"2018-08-14T18:15:50Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"Add a --send-delay option with a corresponding sendemail.smtpSendDelay\nconfiguration variable. When set to e.g. 2, this causes send-email to\nsleep 2 seconds before sending the next E-Mail. We'll only sleep\nbetween sends, not before the first send, or after the last.\n\nThis option has two uses. Firstly, to be able to Ctrl+C a long send\nwith \"all\" if you have a change of heart. Secondly, as a hack in some\nmail setups to, with a sufficiently high delay, force the receiving\nclient to sort the E-Mails correctly.\n\nSome popular E-Mail clients completely ignore the \"Date\" header, which\nformat-patch is careful to set such that the patches will be displayed\nin order, and instead sort by the time the E-mail was received.\n\nGoogle's GMail is a good example of such a client. It ostensibly sorts\nby some approximation of received time (although not by any \"Received\"\nheader). It's more usual than not to see patches showing out of order\nin GMail. To take a few examples of orders seen on patches on the Git\nmailing list:\n\n    1 -> 3 -> 4 -> 2 -> 8 -> 7 (completion by Nguyễn Thái Ngọc Duy)\n    2 -> 0 -> 1 -> 3 (pack search by Derrick Stolee)\n    3 -> 2 -> 1 (fast-import by Jameson Miller)\n    2 -> 3 -> 1 -> 5 -> 4 -> 6 (diff-highlight by Jeff King)\n\nThe reason to add the new \"X-Mailer-Send-Delay\" header is to make it\neasy to tell what the imposed delay was, if any. This allows for\ngathering some data on how the transfer of E-Mails with & without this\noption behaves. This may not be workable without really long delays,\nsee [1] and [2].\n\nThe reason for why the getopt format is \"send-delay=s\" instead of\n\"send-delay=d\" is because we're doing manual validation of the value\nwe get passed, which getopt would corrupt in cases of e.g. float\nvalues before we could show a sensible error message.\n\n1. https://public-inbox.org/git/20180325210132.GE74743@genre.crustytoothpaste.net/\n2. https://public-inbox.org/git/xmqqpo3rehe4.fsf@gitster-ct.c.googlers.com/\n\nSigned-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n---\n\nI submitted this back in March hoping it would solve mail ordering\nproblems, but the other motive I had for this is that I'm paranoid\nthat I'm sending out bad E-Mails, and tend to \"y\" to each one because\n\"a\" is too fast.\n\nSo I'm re-sending this with an updated commit message & rationale, and\nnot sending 2/2 to toggle this on by default. I'd still like to have\nthis feature.\n\n Documentation/config.txt         |  6 ++++\n Documentation/git-send-email.txt |  4 +++\n git-send-email.perl              | 18 ++++++++---\n t/t9001-send-email.sh            | 55 ++++++++++++++++++++++++++++++++\n 4 files changed, 79 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 63365dcf3d..5eb81b64a7 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -3216,6 +3216,12 @@ sendemail.smtpReloginDelay::\n \tSeconds wait before reconnecting to smtp server.\n \tSee also the `--relogin-delay` option of linkgit:git-send-email[1].\n \n+sendemail.smtpSendDelay::\n+\tSeconds wait in between message sending before sending another\n+\tmessage. Set it to 0 to impose no extra delay, defaults to 0.\n++\n+See also the `--send-delay` option of linkgit:git-send-email[1].\n+\n showbranch.default::\n \tThe default set of branches for linkgit:git-show-branch[1].\n \tSee linkgit:git-show-branch[1].\ndiff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt\nindex 465a4ecbed..98fdd9b803 100644\n--- a/Documentation/git-send-email.txt\n+++ b/Documentation/git-send-email.txt\n@@ -270,6 +270,10 @@ must be used for each option.\n \twith --batch-size option.  Defaults to the `sendemail.smtpReloginDelay`\n \tconfiguration variable.\n \n+--send-delay=<int>::\n+\tWait $<int> between sending emails. Defaults to the\n+\t`sendemail.smtpSendDelay` configuration variable.\n+\n Automating\n ~~~~~~~~~~\n \ndiff --git a/git-send-email.perl b/git-send-email.perl\nindex 2be5dac337..65b53ee9f1 100755\n--- a/git-send-email.perl\n+++ b/git-send-email.perl\n@@ -89,6 +89,7 @@ sub usage {\n     --batch-size            <int>  * send max <int> message per connection.\n     --relogin-delay         <int>  * delay <int> seconds between two successive login.\n                                      This option can only be used with --batch-size\n+    --send-delay            <int>  * ensure that <int> seconds pass between two successive sends.\n \n   Automating:\n     --identity              <str>  * Use the sendemail.<id> options.\n@@ -225,7 +226,7 @@ sub do_edit {\n my ($to_cmd, $cc_cmd);\n my ($smtp_server, $smtp_server_port, @smtp_server_options);\n my ($smtp_authuser, $smtp_encryption, $smtp_ssl_cert_path);\n-my ($batch_size, $relogin_delay);\n+my ($batch_size, $relogin_delay, $send_delay);\n my ($identity, $aliasfiletype, @alias_files, $smtp_domain, $smtp_auth);\n my ($validate, $confirm);\n my (@suppress_cc);\n@@ -259,6 +260,7 @@ sub do_edit {\n     \"smtpauth\" => \\$smtp_auth,\n     \"smtpbatchsize\" => \\$batch_size,\n     \"smtprelogindelay\" => \\$relogin_delay,\n+    \"smtpsenddelay\" => \\$send_delay,\n     \"to\" => \\@initial_to,\n     \"tocmd\" => \\$to_cmd,\n     \"cc\" => \\@initial_cc,\n@@ -373,6 +375,7 @@ sub signal_handler {\n \t\t    \"no-xmailer\" => sub {$use_xmailer = 0},\n \t\t    \"batch-size=i\" => \\$batch_size,\n \t\t    \"relogin-delay=i\" => \\$relogin_delay,\n+\t\t    \"send-delay=s\" => \\$send_delay,\n \t );\n \n usage() if $help;\n@@ -484,6 +487,8 @@ sub read_config {\n };\n die sprintf(__(\"Unknown --confirm setting: '%s'\\n\"), $confirm)\n \tunless $confirm =~ /^(?:auto|cc|compose|always|never)/;\n+die sprintf(__(\"Invalid --send-delay setting: '%s'\\n\"), $send_delay)\n+\tif defined $send_delay and $send_delay !~ /^[0-9]+$/s;\n \n # Debugging, print out the suppressions.\n if (0) {\n@@ -1562,7 +1567,8 @@ sub send_message {\n # Returns 0 if an edit was done and the function should be called again, or 1\n # otherwise.\n sub process_file {\n-\tmy ($t) = @_;\n+\tmy ($i) = @_;\n+\tmy $t = $files[$i];\n \n \topen my $fh, \"<\", $t or die sprintf(__(\"can't open file %s\"), $t);\n \n@@ -1741,6 +1747,10 @@ sub process_file {\n \t\t$message, $xfer_encoding, $target_xfer_encoding);\n \tpush @xh, \"Content-Transfer-Encoding: $xfer_encoding\";\n \tunshift @xh, 'MIME-Version: 1.0' unless $has_mime_version;\n+\tif ($send_delay && $i > 0) {\n+\t\tpush @xh, \"X-Mailer-Send-Delay: $send_delay\";\n+\t\tsleep $send_delay;\n+\t}\n \n \t$needs_confirm = (\n \t\t$confirm eq \"always\" or\n@@ -1793,8 +1803,8 @@ sub process_file {\n \treturn 1;\n }\n \n-foreach my $t (@files) {\n-\twhile (!process_file($t)) {\n+foreach my $i (0 .. $#files) {\n+\twhile (!process_file($i)) {\n \t\t# user edited the file\n \t}\n }\ndiff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh\nindex b8e919e25d..791461fabd 100755\n--- a/t/t9001-send-email.sh\n+++ b/t/t9001-send-email.sh\n@@ -1759,6 +1759,61 @@ test_expect_success '--dump-aliases must be used alone' '\n \ttest_must_fail git send-email --dump-aliases --to=janice@example.com -1 refs/heads/accounting\n '\n \n+test_expect_success '--send-delay expects whole non-negative seconds' '\n+\ttest_must_fail git send-email --send-delay=-1 HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors &&\n+\ttest_must_fail git send-email --send-delay=1.5 HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors &&\n+\ttest_must_fail git -c sendemail.smtpSendDelay=-1 send-email HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors &&\n+\ttest_must_fail git -c sendemail.smtpSendDelay=1.5 send-email HEAD~ 2>errors &&\n+\ttest_i18ngrep \"Invalid --send-delay setting\" errors\n+'\n+\n+test_expect_success $PREREQ \"there is no default --send-delay\" '\n+\tclean_fake_sendmail &&\n+\trm -fr outdir &&\n+\tgit format-patch -3 -o outdir &&\n+\tgit send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\toutdir/*.patch \\\n+\t\t2>stderr >stdout &&\n+\ttest $(grep -c \"X-Mailer:\" stdout) = 3 &&\n+\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 0\n+'\n+\n+test_expect_success $PREREQ '--send-delay adds a X-Mailer-Send-Delay header to affected E-Mails' '\n+\tclean_fake_sendmail &&\n+\trm -fr outdir &&\n+\tgit format-patch -3 -o outdir &&\n+\tgit send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t--send-delay=2 \\\n+\t\toutdir/*.patch \\\n+\t\t2>stderr >stdout &&\n+\ttest $(grep -c \"X-Mailer:\" stdout) = 3 &&\n+\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 2\n+'\n+\n+test_expect_success $PREREQ '--send-delay=0 disables any imposed delay on E-Mail sending' '\n+\tclean_fake_sendmail &&\n+\trm -fr outdir &&\n+\tgit format-patch -3 -o outdir &&\n+\tgit -c sendemail.smtpSendDelay=3 send-email \\\n+\t\t--from=\"Example <nobody@example.com>\" \\\n+\t\t--to=nobody@example.com \\\n+\t\t--smtp-server=\"$(pwd)/fake.sendmail\" \\\n+\t\t--send-delay=0 \\\n+\t\toutdir/*.patch \\\n+\t\t2>stderr >stdout &&\n+\ttest $(grep -c \"X-Mailer:\" stdout) = 3 &&\n+\ttest $(grep -c \"X-Mailer-Send-Delay:\" stdout) = 0\n+'\n+\n test_sendmail_aliases () {\n \tmsg=\"$1\" && shift &&\n \texpect=\"$@\" &&\n-- \n2.18.0.865.gffc8e1a3cd6\n\n"},{"id":"355587","messageId":"CAGZ79kZa+VQLfSme2q9UHZEmGYb=7uGgQoNP-BHctq31Js-TGg@mail.gmail.com","threadId":"48142","inReplyTo":"20180814181534.21234-1-avarab@gmail.com","subject":"Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-08-14T18:39:41Z","receivedAt":"2018-08-14T18:39:55Z","isPatch":true,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Aug 14, 2018 at 11:15 AM Ævar Arnfjörð Bjarmason\n<avarab@gmail.com> wrote:\n>\n> Add a --send-delay option with a corresponding sendemail.smtpSendDelay\n> configuration variable. When set to e.g. 2, this causes send-email to\n> sleep 2 seconds before sending the next E-Mail. We'll only sleep\n> between sends, not before the first send, or after the last.\n>\n> This option has two uses. Firstly, to be able to Ctrl+C a long send\n> with \"all\" if you have a change of heart. Secondly, as a hack in some\n> mail setups to, with a sufficiently high delay, force the receiving\n> client to sort the E-Mails correctly.\n>\n> Some popular E-Mail clients completely ignore the \"Date\" header, which\n> format-patch is careful to set such that the patches will be displayed\n> in order, and instead sort by the time the E-mail was received.\n>\n> Google's GMail is a good example of such a client. It ostensibly sorts\n> by some approximation of received time (although not by any \"Received\"\n> header). It's more usual than not to see patches showing out of order\n> in GMail. To take a few examples of orders seen on patches on the Git\n> mailing list:\n>\n>     1 -> 3 -> 4 -> 2 -> 8 -> 7 (completion by Nguyễn Thái Ngọc Duy)\n>     2 -> 0 -> 1 -> 3 (pack search by Derrick Stolee)\n>     3 -> 2 -> 1 (fast-import by Jameson Miller)\n>     2 -> 3 -> 1 -> 5 -> 4 -> 6 (diff-highlight by Jeff King)\n>\n> The reason to add the new \"X-Mailer-Send-Delay\" header is to make it\n> easy to tell what the imposed delay was, if any. This allows for\n> gathering some data on how the transfer of E-Mails with & without this\n> option behaves. This may not be workable without really long delays,\n> see [1] and [2].\n>\n> The reason for why the getopt format is \"send-delay=s\" instead of\n> \"send-delay=d\" is because we're doing manual validation of the value\n> we get passed, which getopt would corrupt in cases of e.g. float\n> values before we could show a sensible error message.\n>\n> 1. https://public-inbox.org/git/20180325210132.GE74743@genre.crustytoothpaste.net/\n> 2. https://public-inbox.org/git/xmqqpo3rehe4.fsf@gitster-ct.c.googlers.com/\n>\n> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>\n> ---\n>\n> I submitted this back in March hoping it would solve mail ordering\n> problems, but the other motive I had for this is that I'm paranoid\n> that I'm sending out bad E-Mails, and tend to \"y\" to each one because\n> \"a\" is too fast.'\n\nHeh. GMail seems to have added an Undo button in their UI, which\nwould be the same feature as this one. (Hit Ctrl+C in time to \"undo\"\nthe sending command)\n\nI have been bitten quite a few times by using \"a\" as I had old\nseries still laying around, such that it would send a new series and parts\nof the old series (or when you changed subjects and resend another\niteration of a series, you may end up with two \"patch 1\"s).\nSo I learned to be careful before pressing \"a\" on sending.\n\nMaybe the underlying issue is that you really only want to send a series\nand not \"all\" as send-email asks for.\nSo maybe that dialog could learn a [s]eries switch, which would\ncheck either filenames to count up, or if the base that is recorded\n(base-commit for first and prerequisite-patch-id for followups)\nis consistent.\n\n    Send this email? ([y]es|[n]o|[e]dit|[q]uit|[a]ll|[s]eries):\n\nAnother note:\nI personally never use no/quit, but Ctrl+C for both cases.\n\nThis is also different than the feature of 5453b83bdf9 (send-email\n--batch-size to work around some SMTP server limit, 2017-05-21)\nwhich introduced sendemail.smtpReloginDelay, which would offer the\nsame functionality when the batch-size is set to 1. (Although this would\nkeep you connected to the server as well as add the X-Mailer-Send-Delay\nheader, which is nothing from the official email RFC, but your own invention?)\n\nHaving sorted mails in GMail would be nice!\n\nThanks,\nStefan\n"},{"id":"355589","messageId":"20180814184509.GA16659@dcvr","threadId":"48142","inReplyTo":"20180814181534.21234-1-avarab@gmail.com","subject":"Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2018-08-14T18:45:09Z","receivedAt":"2018-08-14T18:45:11Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n> Add a --send-delay option with a corresponding sendemail.smtpSendDelay\n> configuration variable. When set to e.g. 2, this causes send-email to\n> sleep 2 seconds before sending the next E-Mail. We'll only sleep\n> between sends, not before the first send, or after the last.\n> \n> This option has two uses. Firstly, to be able to Ctrl+C a long send\n> with \"all\" if you have a change of heart. Secondly, as a hack in some\n> mail setups to, with a sufficiently high delay, force the receiving\n> client to sort the E-Mails correctly.\n> \n> Some popular E-Mail clients completely ignore the \"Date\" header, which\n> format-patch is careful to set such that the patches will be displayed\n> in order, and instead sort by the time the E-mail was received.\n> \n> Google's GMail is a good example of such a client. It ostensibly sorts\n> by some approximation of received time (although not by any \"Received\"\n> header). It's more usual than not to see patches showing out of order\n> in GMail. To take a few examples of orders seen on patches on the Git\n> mailing list:\n> \n>     1 -> 3 -> 4 -> 2 -> 8 -> 7 (completion by Nguyễn Thái Ngọc Duy)\n>     2 -> 0 -> 1 -> 3 (pack search by Derrick Stolee)\n>     3 -> 2 -> 1 (fast-import by Jameson Miller)\n>     2 -> 3 -> 1 -> 5 -> 4 -> 6 (diff-highlight by Jeff King)\n> \n> The reason to add the new \"X-Mailer-Send-Delay\" header is to make it\n> easy to tell what the imposed delay was, if any. This allows for\n> gathering some data on how the transfer of E-Mails with & without this\n> option behaves. This may not be workable without really long delays,\n> see [1] and [2].\n\nAside from the new header, I think this is better implemented\nusing the existing $relogin_delay and $batch_size=1.\n\nDisconnecting during the delay might be more sympathetic to\nexisting mail servers (which aren't C10K-optimized).  If the\nclient sleeps, the server may disconnect the client anyways\nto save resources.\n\n> @@ -1741,6 +1747,10 @@ sub process_file {\n>  \t\t$message, $xfer_encoding, $target_xfer_encoding);\n>  \tpush @xh, \"Content-Transfer-Encoding: $xfer_encoding\";\n>  \tunshift @xh, 'MIME-Version: 1.0' unless $has_mime_version;\n> +\tif ($send_delay && $i > 0) {\n> +\t\tpush @xh, \"X-Mailer-Send-Delay: $send_delay\";\n> +\t\tsleep $send_delay;\n> +\t}\n\nWe can add this header for relogin_delay + batch_size\n\nBut maybe --send-delay can be a shortcut for\n--relogin-delay and --batch-size=1\n"},{"id":"355603","messageId":"xmqqftzg209i.fsf@gitster-ct.c.googlers.com","threadId":"48142","inReplyTo":"20180814184509.GA16659@dcvr","subject":"Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-08-14T19:53:13Z","receivedAt":"2018-08-14T19:53:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong <e@80x24.org> writes:\n\n>> Some popular E-Mail clients completely ignore the \"Date\" header, which\n>> format-patch is careful to set such that the patches will be displayed\n>> in order, and instead sort by the time the E-mail was received.\n\nIt is send-email that carefully shows monotonically increasing\ntimestamps so that the sender's datestamp can be used for sorting by\nthe recipient, not format-patch, which records author-date,\nprimarily meant for local replaying, in the generated messages but\ndiscarded by send-email.\n\n> Disconnecting during the delay might be more sympathetic to\n> existing mail servers (which aren't C10K-optimized).  If the\n> client sleeps, the server may disconnect the client anyways\n> to save resources.\n>\n> But maybe --send-delay can be a shortcut for\n> --relogin-delay and --batch-size=1\n\nBoth good points to point at a simpler and better solution, I guess.\n\n\n"},{"id":"355620","messageId":"87eff0hdaj.fsf@evledraar.gmail.com","threadId":"48142","inReplyTo":"20180814184509.GA16659@dcvr","subject":"Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-14T21:02:44Z","receivedAt":"2018-08-14T21:02:50Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Aug 14 2018, Eric Wong wrote:\n\n> Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:\n>> Add a --send-delay option with a corresponding sendemail.smtpSendDelay\n>> configuration variable. When set to e.g. 2, this causes send-email to\n>> sleep 2 seconds before sending the next E-Mail. We'll only sleep\n>> between sends, not before the first send, or after the last.\n>>\n>> This option has two uses. Firstly, to be able to Ctrl+C a long send\n>> with \"all\" if you have a change of heart. Secondly, as a hack in some\n>> mail setups to, with a sufficiently high delay, force the receiving\n>> client to sort the E-Mails correctly.\n>>\n>> Some popular E-Mail clients completely ignore the \"Date\" header, which\n>> format-patch is careful to set such that the patches will be displayed\n>> in order, and instead sort by the time the E-mail was received.\n>>\n>> Google's GMail is a good example of such a client. It ostensibly sorts\n>> by some approximation of received time (although not by any \"Received\"\n>> header). It's more usual than not to see patches showing out of order\n>> in GMail. To take a few examples of orders seen on patches on the Git\n>> mailing list:\n>>\n>>     1 -> 3 -> 4 -> 2 -> 8 -> 7 (completion by Nguyễn Thái Ngọc Duy)\n>>     2 -> 0 -> 1 -> 3 (pack search by Derrick Stolee)\n>>     3 -> 2 -> 1 (fast-import by Jameson Miller)\n>>     2 -> 3 -> 1 -> 5 -> 4 -> 6 (diff-highlight by Jeff King)\n>>\n>> The reason to add the new \"X-Mailer-Send-Delay\" header is to make it\n>> easy to tell what the imposed delay was, if any. This allows for\n>> gathering some data on how the transfer of E-Mails with & without this\n>> option behaves. This may not be workable without really long delays,\n>> see [1] and [2].\n>\n> Aside from the new header, I think this is better implemented\n> using the existing $relogin_delay and $batch_size=1.\n>\n> Disconnecting during the delay might be more sympathetic to\n> existing mail servers (which aren't C10K-optimized).\n\nYeah that's a good point, maybe we're being wasteful on remote resources\nhere.\n\n> If the client sleeps, the server may disconnect the client anyways to\n> save resources.\n\nSeems like something we'd need to deal with anyway, do we?\n\n>> @@ -1741,6 +1747,10 @@ sub process_file {\n>>  \t\t$message, $xfer_encoding, $target_xfer_encoding);\n>>  \tpush @xh, \"Content-Transfer-Encoding: $xfer_encoding\";\n>>  \tunshift @xh, 'MIME-Version: 1.0' unless $has_mime_version;\n>> +\tif ($send_delay && $i > 0) {\n>> +\t\tpush @xh, \"X-Mailer-Send-Delay: $send_delay\";\n>> +\t\tsleep $send_delay;\n>> +\t}\n>\n> We can add this header for relogin_delay + batch_size\n>\n> But maybe --send-delay can be a shortcut for\n> --relogin-delay and --batch-size=1\n\nI need to enter a password when sending a batch with my SMTP server now,\nonce. With relogin I'd need to enter this N times unless I use whatever\nauth save facility there is in git-send-email (which I don't use now).\n\nI don't think it makes sense to conflate these two modes.\n"}]}