Re: Transient SMTP errors
- From: Peter Bloomfield <PeterBloomfield bellsouth net>
- To: balsa-list gnome org
- Subject: Re: Transient SMTP errors
- Date: Sat, 27 May 2017 17:48:29 -0400
-----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-----
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]