Transient SMTP errors

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Transient SMTP errors

Peter Bloomfield
Dear List,

Albrecht's recent changes to the message sending code are really useful: if sending messages fails because the server cannot be reached, the messages can be resent by a simple control-T (or File => Send Queued Mail)--no need to clear any flags.

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, 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!

Best,

Peter
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

transient-errors.diff (3K) Download Attachment
attachment1 (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

Albrecht Dreß
Hi Peter:

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,

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 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.

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.

Cheers,
Albrecht.
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

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

On 05/27/2017 01:08:02 PM Sat, Albrecht Dreß wrote:

> Hi Peter:
>
> 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,
>
> 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 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.

OK, I'll commit it.

> 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.

That will take a bit of care. We'll need to be able to cancel the timer if the user queues some mail for sending, b/c that could mean that the user is preparing messages to be sent out in a single batch--I've used it that way to reach a number of people who need to be notified as close to simultaneously as possible. I'm sure there are other nuances, too.

Best,

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

iEYEARECAAYFAlkpuI8ACgkQH1/UtbkqdPWIFACggubFaP3mW34ZVJ1DlyadV7mO
B3kAniBBShshpQrkHXhnxp+mSMPXMW5t
=LI3i
-----END PGP SIGNATURE-----
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

Jack
In reply to this post by Albrecht Dreß
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.

> 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)?
>
> Cheers,
> Albrecht.

Jack
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

Peter Bloomfield
-----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
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

Albrecht Dreß
Hi Peter and Jack:

Am 27.05.17 23:48 schrieb(en) Peter Bloomfield:
> 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.

What about the following:

(1) Add a new config option "Try to send queued messages every ... minutes" which can be disabled completely or configured by the user for a timeout (default: 15 minutes).

The next items apply only if the option is enabled.  Ready-to-send messages means messages in the outbox which are neither flagged nor deleted.

(2) When balsa is started, count the ready-to-send messages.  Launch the timer if the count is > 0.

(3) User selects to queue a newly composed message:  Stop the timer if it is running, and add the new message to outbox.  Start the timer again unless a send operation is running in a separate thread.

(4) User selects to send a newly composed message:  Stop the timer if it is running, and add the new message to outbox.  If a send operation is running in a separate thread, set a "retrigger send" flag.  Otherwise, launch the send operation for all ready-to-send messages.

(5) Send operation (either from sending a new message, or from manually sending the queue):  Stop the timer if it is running.  Launch the network check.  On success start the thread to send all ready-to-send messages.  If no transient error occurred and the "retrigger send" flag is set, clear it and again send all ready-to-send messages, until either an error occurred or the flag is not set.  In all cases, re-start the timer if at least one ready-to-send message is left in outbox.

(6) Manually un-flagging a message in the outbox does not affect the timer.  I.e. the user in this case shall manually trigger the send operation (or items 2, 3 or 4 above will trigger the send operation).

What do you think, would this reasonably catch all use cases?

Cheers,
Albrecht.
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

JohnJackDoe
Hi all,

I watched the discussion for a while.

My proposal is that the user has an additional 'send to queue' button.  
This would flag (on hold) the message and send it  to the queue only  
without further action. The already available 'send' button would send  
it not flagged (ready for transfer) to queue for immediate transfer.

The retry timeout (client has given up and noticed the user) should be  
user adjustable and the retry timer (time interval for retry) too.

What are your opinions?
--
Best regards

John Jack Doe

On 28 May 2017 12:22:19, Albrecht Dreß wrote:

> Hi Peter and Jack:
>
> Am 27.05.17 23:48 schrieb(en) Peter Bloomfield:
>> 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.
>
> What about the following:
>
> (1) Add a new config option "Try to send queued messages every ...  
> minutes" which can be disabled completely or configured by the user  
> for a timeout (default: 15 minutes).
>
> The next items apply only if the option is enabled.  Ready-to-send  
> messages means messages in the outbox which are neither flagged nor  
> deleted.
>
> (2) When balsa is started, count the ready-to-send messages.  Launch  
> the timer if the count is > 0.
>
> (3) User selects to queue a newly composed message:  Stop the timer  
> if it is running, and add the new message to outbox.  Start the timer  
> again unless a send operation is running in a separate thread.
>
> (4) User selects to send a newly composed message:  Stop the timer if  
> it is running, and add the new message to outbox.  If a send  
> operation is running in a separate thread, set a "retrigger send"  
> flag.  Otherwise, launch the send operation for all ready-to-send  
> messages.
>
> (5) Send operation (either from sending a new message, or from  
> manually sending the queue):  Stop the timer if it is running.  
> Launch the network check.  On success start the thread to send all  
> ready-to-send messages.  If no transient error occurred and the  
> "retrigger send" flag is set, clear it and again send all  
> ready-to-send messages, until either an error occurred or the flag is  
> not set.  In all cases, re-start the timer if at least one  
> ready-to-send message is left in outbox.
>
> (6) Manually un-flagging a message in the outbox does not affect the  
> timer.  I.e. the user in this case shall manually trigger the send  
> operation (or items 2, 3 or 4 above will trigger the send operation).
>
> What do you think, would this reasonably catch all use cases?
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

Albrecht Dreß
Am 28.05.17 20:09 schrieb(en) [hidden email]:
> My proposal is that the user has an additional 'send to queue' button. This would flag (on hold) the message and send it  to the queue only without further action. The already available 'send' button would send it not flagged (ready for transfer) to queue for immediate transfer.

What exactly would be the difference to the behaviour of the existing “File → Send” and “File → Queue” composer menu items?  Or is just the toolbar button missing for the latter?

> The retry timeout (client has given up and noticed the user) should be user adjustable

The client timeouts are defined by RFC 5321, sect. 4.5.3.2.1. - 4.5.3.2.6., inclusively.

> and the retry timer (time interval for retry) too.

Yes.  I'm working on an implementation which will have a range of 1..120 minutes.

Cheers,
Albrecht.
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

JohnJackDoe
On 29 May 2017 18:16:10, Albrecht Dreß wrote:

> Am 28.05.17 20:09 schrieb(en) [hidden email]:
>> My proposal is that the user has an additional 'send to queue'  
>> button. This would flag (on hold) the message and send it  to the  
>> queue only without further action. The already available 'send'  
>> button would send it not flagged (ready for transfer) to queue for  
>> immediate transfer.
>
> What exactly would be the difference to the behaviour of the existing  
> “File → Send” and “File → Queue” composer menu items?  Or is just the  
> toolbar button missing for the latter?

I think nothing. I didn't notice this option before because there is no  
button. I have to apologise formally for my mistake.
--
Best regards

John Jack Doe
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Transient SMTP errors

Albrecht Dreß
Am 29.05.17 21:25 schrieb(en) [hidden email]:
>> What exactly would be the difference to the behaviour of the existing “File → Send” and “File → Queue” composer menu items?  Or is just the toolbar button missing for the latter?
>
> I think nothing. I didn't notice this option before because there is no button.

O.k...

> I have to apologise formally for my mistake.

Please don't!  These discussions and your input are always *really* very helpful.  To be honest, I didn't notice that the toolbar button is missing before you asked...

And I think this button should actually be added.  Any artist out there with an idea for a nice icon?

Cheers,
Albrecht.
_______________________________________________
balsa-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/balsa-list

attachment0 (484 bytes) Download Attachment
Loading...