Deprecate retry on failure

[ivy]

As it is now, we only make this attempt when the SMTP client exceeds it's configured read/write deadline. Unfortunately, this feature's been mistaken to also handle server-side timeouts (i.e., when the server disconnects an idle client). I'm sorry to say, that's not a goal of this project as SMTP servers differ too greatly for it to be maintainable (see #15 (comment)).

I believe it was a mistake to have implemented this feature in the first place and I'd like to deprecate it. Instead, users of this library should not rely on this functionality and ensure they're properly checking delivery errors and redialing. Before making any changes, I'd like to leave this issue open to allow some feedback.

[steviesama]

@ivy So I mapped out logging for all the functions called starting with DialAndSend()...I'm about to push it to live...so I won't see the results until the next hangup...but I think this retry feature might be causing an infinite retry recursive loop...

I could be missing it...but I haven't noticed anything that lets it escape...and I am definitely experiencing intermittent hangs...lasting at least 20 minutes before I've restarted the server. It seems to only be if it's a timeout...but it seems to be infinite in that case.

I wouldn't necessarily expect it to time out every single time...but there could be something going on in a dialing instance that perpetuates the timeout...when the go routine I run it from stops responding...I restart the server and it reloads all the email campaign jobs and they send like normal...until the next time.