Jump to content

Recommended Posts

I'm setting up the SMTP Server settings in eSet Remote Administrator v6.5.417.0 and I'm using the following settings and I cannot get eSet RA to send email. The Send test email function fails with the timeout (Test email has not been successfully sent. Request timeout 90000ms exceeded.) Should this service work with Gmail at all? Is there something that I'm missing? 

(all settings are identical to other services that I have that are working to send email reports regularly)

  • Host - smtp.gmail.com
  • Port - 587
  • Username - verified user in G Suite
  • Password - verified app password for user above
  • Connection security type - TLS
  • Authentication type - Automatic (I've tried External, Plain, Login and Automatic)

 

 

Link to comment
Share on other sites

It's poor form to reply to your own post, but I fixed this and thought I'd report back to let folks know what I did. 

I'm using the RA virtual appliance, so I enabled Webmin and took a look at what needed to be updated on the server. I ran the updates that were available, fixed the subsequent MySQL connectivity issues that resulted from the updates, and tried again. Lo and behold, everything worked. With a few changes...

  • Password - re-entered the same password as above (copy & paste)
  • Port - 465

That's it. I thought it might be the Linux Firewall but no. All outbound was allowed by default. So there must have been an update that was needed or when I thought I checked port 465 yesterday, I just needed to re-enter the password. I'm sorry I can't pinpoint the exact thing that fixed this, but the reality is that there shouldn't have been an issue to begin with. 

Link to comment
Share on other sites

  • ESET Staff

In your specific case,my guess is that specific configuration caused that sending of email resulted in "deadlock", where both client and server were waiting for remote peer activity. This might happen especially in case connection security type is not properly configured. I guess that restarting ERA service (triggered by system update) with proper configuration actually resolved this.

Just for future reference, following hostname/port/security configurations should work with smtp.gmail.com:

  • smtp.gmail.com, 587, STARTTLS, Login, Plain or Automatic authentication
  • smtp.gmail.com, 465, TLS, Login, Plain or Automatic authentication

Also be aware, that it might be required to enable less secure apps access your account which is caused by fact that ERA does not support OAUTH authentication method which is the only considered as security for this server.

 

Link to comment
Share on other sites

9 minutes ago, MartinK said:

In your specific case,my guess is that specific configuration caused that sending of email resulted in "deadlock", where both client and server were waiting for remote peer activity. This might happen especially in case connection security type is not properly configured. I guess that restarting ERA service (triggered by system update) with proper configuration actually resolved this.

Just for future reference, following hostname/port/security configurations should work with smtp.gmail.com:

  • smtp.gmail.com, 587, STARTTLS, Login, Plain or Automatic authentication
  • smtp.gmail.com, 465, TLS, Login, Plain or Automatic authentication

Also be aware, that it might be required to enable less secure apps access your account which is caused by fact that ERA does not support OAUTH authentication method which is the only considered as security for this server.

 

Thank you very much for the verification and extra info. 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...