Re: [PATCH v5] send-email: --batch-size to work around some SMTP server limit

[Jan Viktorin <viktorin@rehivetech.com>]

On Tue, 23 May 2017 16:46:27 +0900
Junio C Hamano <gitster@pobox.com> wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
> > Looking at this the Nth time now though I wonder about this approach
> > in general. In all your E-Mails I don't think you ever said /what/
> > sort of error you had from the SMTP server, you just said you had a
> > failure or an error, I assume you hit one of the die's in the
> > send_message() function. Can you paste the actual error you get
> > without this patch?

Hello,

I have issues with a company SMTP server that returns:

Net::SMTP::SSL=GLOB(0x20d6510)<<< 451 4.3.0 Please try again later,
rate limited.
4.3.0 Please try again later, rate limited.

Unfortunately, I didn't find out the exact properties of the limit yet.
It seems that sending more then 10 patches at once fails. Thus, I have
to send longer patch sets in 2 rounds:

1. normal git send-email
2. git send-email --no-thread --in-reply-to="<COVER LETTER ID>" \
     <REST-OF-PATCHES>...

It is not exactly the same as sending all the patches at once.

The xiaoqiang's solution sounds promising to me. However, probably a
more general solution would be to "just" enable sending a whole patch
set in 2 rounds manually. But I didn't find any way how to do it right.

Regards
Jan

> >
> > I wonder if something like this would Just Work for this case without
> > any configuration or command-line options, with the added benefit of
> > just working for anyone with transitory SMTP issues as well (patch
> > posted with -w, full version at
> > https://github.com/avar/git/commit/acb60c4bde50bdcb62b71ed46f49617e2caef84e.patch):  
> 
> Yeah, if the issues users of 163.com are having can be resolved with
> a more general approach like this, that would be very much preferred.
> 
> > Now that's very much a WIP and I don't have a server like that to test against.
> >
> > Having worked with SMTP a lot in a past life/job, I'd say it's *very*
> > likely that you're just getting a /^4/ error code from 163.com,
> > probably 421, which would make this logic even simpler. I.e. we could
> > just adjust this to back-off for /^4/ instead of trying to handle
> > arbitrary errors.
> >
> > Anyway, I'm not interested in pursuing that WIP patch, and I don't
> > think perfect should be the enemy of the good here. Your patch works
> > for you, doesn't really damage anything else, so if you're not
> > interested in hacking up something like the above I think we should
> > just take it.
> >
> >
> > But I do think it would be very good to get a reply to you / details
> > in the commit message about what error you get exactly in this
> > scenario, see if you get better details with --smtp-debug, and if so
> > paste that (sans any secret info like user/password you don't want to
> > share).  
> 
> Let's wait for a few days to see if xiaoqiang wants to take your
> outline of more general approach and polish it.  I do prefer the "no
> config" solution as xiaoqiang won't be the only 163.com user, but
> Individual Contributors cannot be forced, so ...
> 
> Thanks.