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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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?
>
> 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.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]