On Tue, Aug 14 2018, Eric Wong wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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]. > > Aside from the new header, I think this is better implemented > using the existing $relogin_delay and $batch_size=1. > > Disconnecting during the delay might be more sympathetic to > existing mail servers (which aren't C10K-optimized). Yeah that's a good point, maybe we're being wasteful on remote resources here. > If the client sleeps, the server may disconnect the client anyways to > save resources. Seems like something we'd need to deal with anyway, do we? >> @@ -1741,6 +1747,10 @@ sub process_file { >> $message, $xfer_encoding, $target_xfer_encoding); >> push @xh, "Content-Transfer-Encoding: $xfer_encoding"; >> unshift @xh, 'MIME-Version: 1.0' unless $has_mime_version; >> + if ($send_delay && $i > 0) { >> + push @xh, "X-Mailer-Send-Delay: $send_delay"; >> + sleep $send_delay; >> + } > > We can add this header for relogin_delay + batch_size > > But maybe --send-delay can be a shortcut for > --relogin-delay and --batch-size=1 I need to enter a password when sending a batch with my SMTP server now, once. With relogin I'd need to enter this N times unless I use whatever auth save facility there is in git-send-email (which I don't use now). I don't think it makes sense to conflate these two modes.