SMTP SendEmail Inconsistent Results

I’m using UiPath.Mail.SMTP.Activities.SendEmail (1.12.3) to send emails, which I’ve used successfully in multiple previous automations. My test involves sending an email without a screenshot attachment, then another with a screenshot attachment. All of this is being done in Studio. I am currently working from home via a VPN, but have the same results when on-site connected directly to our network. (I have tried with version 1.15.2 with the same results). Also, it doesn’t matter if I use strings for the activity properties or variables.

The first time after rebooting my laptop:

  • the email without a screenshot goes through without issue
  • the email with a screenshot just hangs - I cannot even perform a break in Studio, it can only be stopped. Studio itself is NOT hung, just the SendMail activity.

After stopping the run, I started a second run:

  • the email without a screenshot times out per the TimeoutMS setting (Send SMTP Mail Message w/o screenshot: Timed out while waiting for Mail Service to connect)
  • the email with a screenshot just hangs - same as the first time.

Subsequent runs result in the same results. Any ideas what is causing this?

Try to update your UiPath Studio to 2022.4.4 and use the 1.15.2 version of UiPath.Mail.Activities as we had some bug fixes.

Let us know if this helped.

I wish I could do that! Our company policy is that we are required to use Studio 2021.10.4, but I will try 1.15.2 again for the activities.

Hello, I had myself too, some problems with sending emails.
The SMTP protocol was more related to messages for GMail accounts.
Or can be similar, regarding the issues, that are being encountered.
What I know, is there are some changes in the policy of security.
The email delivering services don’t accept less secure applications.
Last time, it was a setting for allowing rights to other applications.
Now it’s been required a second access key. to allow working a robot.
I think, now it’s time to check the settings for the email account.

Fine Regards, Adrian

I can only surmise that the result was to be on-site connected directly to our network. It seems to be working consistently under those conditions.

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.