Re: Transient SMTP errors

[Peter Bloomfield <PeterBloomfield bellsouth net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jack,

On 05/27/2017 02:27:21 PM Sat, Jack wrote:
> Hello all,
>
> On 2017.05.27 13:08, Albrecht Dreß wrote:
> > Am 27.05.17 18:48 schrieb(en) Peter Bloomfield:
> > > With my AT&T/Yahoo server, I more often get errors like "connection lost", or "transient error" with something about 
> > > "internal server error". As far as I know, these also require no action except resending,
> Yahoo seems to be notoriously bad, especially for email service they provide for other ISPs, which ends up 
> meaning it seems to be incredibly difficult to get any actual technical support.  They provide POP3, IMAP, 
> and SMTP, but they seem to frequently end up telling you to use the web mail interface.  Anything which helps 
> avoid that is a good thing in my view.
>
> > This is at least what RFC 5321, Sect. 4.2.1. says...
>
> > BTW, now that everything runs in background, I think I should adjust the timeouts according to RFC 5321, 
> > Sect. 4.5.3.2., which may also ease your issues.
> > > but currently I first have to clear the flag.
> > >
> > > The attached patch clears the flags with these two types of error. Does that look reasonable? Is there a 
> > > better way to use the new error-handling code? All feedback welcome!
> I'm happy with the ability to (if I can remember) use Ctl-T without having to clear the flag first.
>
> > I think this is a *really* useful change!  I do not have these issues (my ISP is bad, but apparently not 
> > /that/ bad...), but the use case you describe makes sense.
> I really believe the issue is related to Yahoo providing the email service for the ISP, so the problem is not 
> really the ISP itself.

<rant>AT&T used to host their own POP3 and SMTP servers, and they were, as I recall, standards-compliant and quite 
reliable. Then they *chose* to outsource it to Yahoo, and the rest is the history you describe. So the problem really *is* 
the ISP and the choice they made!</rant>

> > The next step would now be an automatic re-send of the queue, as requested by user John Jack Doe, probably 
> > with an option to disable it if the user prefers to control it manually.
> If this is done, is there, or could there be a pop-up (once per batch send attempt, not per message) saying 
> that sending failed and Balsa will continue to try (for a set number of times?  for a set period of time?  
> other limits?) to send.  As has been mentioned in other replies (unless it's just my imagination :-) it would 
> be good to be able to stop the attmepts, or even prevent them by a configuration setting.  Per Peter's 
> mention - if you cancel the resends due to the user creating new outgoing messages, when those are sent, 
> would it be reasonable to also retry the stuck message(s)?

Yes, we need to discuss the UI. As for creating new outgoing messages: when any message is sent, the whole 
queue in Outbox is sent, except for any messages with the FLAGGED flag (or DELETED, of course). Essentially, 
any message in Outbox that is not FLAGGED is viewed as queued for sending, regardless of its history.

Best,

Peter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlkp9C4ACgkQH1/UtbkqdPWWHgCeLKj4hIDWyMCOOJ9MidnDtC4o
vyUAnRRDFFcEH6RITpt+q6I6B0SPndcn
=i+yq
-----END PGP SIGNATURE-----