-----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-----
_______________________________________________
balsa-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/balsa-list
