Subject: Re: [PATCH] send-mail: Add option to sleep between sending each email.

From: Georgi Chorbadzhiyski <[email-masked]>
Date: Thu, 08 Sep 2011 12:11:20 +0300

Around 09/08/2011 11:43 AM, Ramkumar Ramachandra scribbled:
> Hi Georgi,
> 
> Georgi Chorbadzhiyski writes:
>> Sometimes when sending lots of changes it is not nice
>> to send emails as fast as possible. Of course you can
>> confirm each email after waiting couple of seconds but
>> this is not optimal. This patch adds --sleep option
>> to git-send-mail and corresponding sendmail.sleep config
>> variable to control how much seconds to wait between
>> sending each email. The default is 0 (not wait at all).
> 
> I use git-send-email a lot, and I ask it to print out the list of all
> emails once before confirming.  After confirming, I just switch back
> to Emacs and continue work- in the many instances, I've never actually
> needed to slow the process down.  If anything, I wished it could
> concurrently send many emails and do things /faster/ *.   I'm a little
> curious about why you want to slow it down- is your SMTP server
> configured to block you because it suspects that you're trying to
> spam?
> 
> Thanks.
> 
> * I first need to see if SMTP servers today can take in emails at this
> speed without suspecting spam.

It is not the mail server, it is workaround mainly for web archives and
MUAs that look at received dates when sorting threads.

When they receive a lot of email in one thread very quickly (and out of
order) they do not thread correctly.

See for example this: http://mailman.videolan.org/pipermail/dvblast-devel/2011-August/thread.html
The thread named: [dvblast-devel] [PATCH 0/4] Post git migration changes
See how 1,3,4/4 are not detected to be part of the thread even when
all headers are set correctly by git-send-email.

Probably my mail server send them out of order and that is why I have
the idea to introduce some small delay between sending each email. Easier
on the MTA, works around the possibility to send emails out of order
the flip side is that it takes more time.

-- 
Georgi Chorbadzhiyski
http://georgi.unixsol.org/