Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails
On Tue, Aug 14 2018, Eric Wong wrote:
> Ævar Arnfjörð Bjarmason 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.
Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails
Eric Wong writes: >> 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. It is send-email that carefully shows monotonically increasing timestamps so that the sender's datestamp can be used for sorting by the recipient, not format-patch, which records author-date, primarily meant for local replaying, in the generated messages but discarded by send-email. > Disconnecting during the delay might be more sympathetic to > existing mail servers (which aren't C10K-optimized). If the > client sleeps, the server may disconnect the client anyways > to save resources. > > But maybe --send-delay can be a shortcut for > --relogin-delay and --batch-size=1 Both good points to point at a simpler and better solution, I guess.
Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails
Ævar Arnfjörð Bjarmason 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). If the
client sleeps, the server may disconnect the client anyways
to save resources.
> @@ -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
Re: [PATCH v2] send-email: add an option to impose delay sent E-Mails
On Tue, Aug 14, 2018 at 11:15 AM Ævar Arnfjörð Bjarmason 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.ge74...@genre.crustytoothpaste.net/ > 2. https://public-inbox.org/git/xmqqpo3rehe4@gitster-ct.c.googlers.com/ > > Signed-off-by: Ævar Arnfjörð Bjarmason > --- > > 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
