Re: [PATCH] send-email: new option to walkaround email server limits

xiaoqiang zhao [off-list ref] writes:

Some email server(e.g. smtp.163.com) limits a fixed number emails to be send per
session(connection) and this will lead to a send faliure.

That sounds painful.

With --split <num> option, a auto reconnection will occur when number of sended
email reaches <num> and the problem is solved.

Two nits (other than s/sended/sent/ and s/$send_count/$num_sent/):

 - "--split" sounds as if you are splitting a single large message
   into multiple pieces, which of course is not what is going on
   here.  We need to find a better name for the option.  Perhaps
   "--batch-size=<num>", "--max-messages-per-connection=<num>" or
   something?

 - The code seems to do the "logging out and the logging back in"
   dance without any delay in between.  Is it something we want to
   consider to add a small (possibly configurable) delay in between?

Thanks.

Thanks for your reply , Junio !

在 2017年5月1日，09:54，Junio C Hamano [off-list ref] 写道：

here.  We need to find a better name for the option.  Perhaps
  "--batch-size=<num>", "--max-messages-per-connection=<num>" or
  something?

--batch-size is ok with me

It' s a good idea to have a configurable delay.

On Mon, May 1, 2017 at 8:03 AM, 赵小强 [off-list ref] wrote:

Thanks for your reply , Junio !

quoted

在 2017年5月1日，09:54，Junio C Hamano [off-list ref] 写道：

here.  We need to find a better name for the option.  Perhaps
  "--batch-size=<num>", "--max-messages-per-connection=<num>" or
  something?

--batch-size is ok with me

quoted

- The code seems to do the "logging out and the logging back in"
  dance without any delay in between.  Is it something we want to
  consider to add a small (possibly configurable) delay in between?

It' s a good idea to have a configurable delay.

It makes sense to have a configurable delay for git-send-email
unrelated to this option, I'd use a facility like that.

A lot of mail clients just sort based on date/msgid or whatever not
date/subject, so the rapid-fire output of send-email often arrives out
of order because it's all sent at the same second. I'd use some option
where I could send a series as "all" and have it sleep(N) in between
sending mails.