Not a bug

OTP email is no longer being sent from the default from address

Simon 2 years ago updated 2 years ago 5

I updated to the new stable version of v19.3 that was released today (v19.3.25541) and I noticed that the OTP email is being sent from cloud@screenconnect.com instead of the default from address that I had configured in my mail settings.

Email invitations are working fine. This issue is isolated to the OTP email.

ConnectWise Control Version:
Server Affected:
Host Client Affected:
Guest Client Affected:
Not a bug

Hi Simon, 

This was a recent change that will only affect OTP emails. Because of our recent focus on security practices, we want to make sure these OTP emails are always successfully delivered. All other emails will not be affected by this change. 

Hi Caitlin,

Thank you for the swift response.

Given that OTP emails are going to be sent from cloud@screenconnect.com from now on, I'd like it if you could fix the following bug I've encountered.

I'm using a Japanese language extension which was working fine prior to today's update, but is now broken.

It seems that the values for the web resource strings EmailAuthenticationProviderBodyFormat and EmailAuthenticationProviderSubjectFormat provided by the extension are no longer being interpreted correctly as they're passed to cloud@screenconnect.com for delivery, resulting in the garbled text you seen in the image attached below.

The extension continues to work perfectly for all other emails, as is shown by the email invite in the attached image.

In any case, the issue isn't with the extension itself. The problem persists even when the Japanese text is manually set as custom values for the web resource strings in the Appearances page.

Could you look into this?

P.S. I've now confirmed that the garbling occurs for non-Latin alphabets. I've tried Hebrew, Greek, Arabic, Cyrillic, Korean and Chinese. Every letter is replaced by a question mark.

Thanks for reporting Simon, we'll investigate. 

Hi Caitlin, any update on this issue with non-Latin alphabets?

I've since found that LoginPanel.ResetPasswordEmailBodyFormat is subject to garbling as well, when non-Latin characters are used.

Commenting disabled