SMTPSecureSocket Send Issues

From researching the forum it seems that the SMTPSecureSocket might be lagging on the security protocols, and that might have something to do with the issues I’m having.

The basic problem I am having is that when I call SendMail() I sometimes get either a 102 Connection Lost or a 336130315 Handshake Failed error almost immediately. The MessageSent() and MailSent() events don’t fire and the outgoing email is still in the Messages() array. My app waits 30 seconds and calls SendMail() again. And, again, sometimes I get another 102 or 336130315 error without any of the *Sent() events firing and the message still being in the array. So far, by the third retry attempt the message sends without errors and the *Sent() events fire and the Messages() array is empty.

The issue I am having is that even though I get these errors and the *Sent events don’t fire, most of the time the email is actually sent. So the recipient can end up with several copies of the same email.

I’m guessing that whatever goes wrong happens between the socket’s “sending” of the message and the socket’s receipt of the server’s “sent” confirmation, but there’s no visibility into that for me (that I know of) and I have no way of knowing if the message was actually sent so I can skip the retries.

I feel like there’s not much I can do about this, but I am always full of hope :slight_smile:

FWIW: Xojo2023v1.1, Web2 App, using a GoDaddy mail server for testing, production will be Outlook for internal corporate use.

One thing I have found with SMTPSecureSocket is that SendMail can be invoked while the socket is in the state of sending mail, so you start getting Server Errors. To get around this I created a subclass and added a timer to invoke sendmail which is disabled when sending & enabled in mailsent.

Thanks for that insight, Wayne. I already have it subclassed with a lot of logging and event interception going on, but I will add code to handle that situation. SendMail is called after a batch of incoming emails is processed, but there can certainly be a case where the next batch of replies is ready to go while SendMail is still doing its thing from the previous batch.