Notifications - Message content - missing "Object URI" variable

[CraigF 0]

Hi,

We're migrating our on-prem ESET Protect console functionality to the ESET PROTECT cloud console. In recreating our Malware alert notifications I've noticed that the "Object URI" variable (${object_uri}) is not available. It is in our on-prem version. Refer screen grabs of available fields below.

This is an important piece of information to include in the notification so it seems strange that it wouldn't be included in the cloud version.

Variables available on-prem:

Variables available in cloud:
 

Edited Monday at 05:18 AM by CraigF
Minor typo correction.

[MartinK 382]

This type of information was intentionally excluded, as there was a potential risk that users would receive HTTP link with potentially malicious content in a email verified and signed by ESET itself.

As of now, there are plans to enable this field also in cloud notifications, but currently without exact ETA.
 

[CraigF 0]

Thanks for the status update, Martin.

I can understand the logic for not including this field in the default notification message, but it doesn't make sense to not make it an available field when it is available in the on-premise version. I also expect that these notifications would generally be configured to go to administrators, not end users. Receiving a notification that doesn't identify what triggered it is not particularly helpful to an administrator.

I hope the dev team can make the availability of this field a priority.

[igi008 19]

Many thanks for your suggestion. I absolutely agree that this would be useful, and we have discussed adding it many times to the cloud version as well. The main difference is that in the on-premises version, the customer configures their own SMTP server and they are responsible for their reputation. In the cloud version, ESET is responsible for the messaging service and servers. There can be some issues when customers have set up object URIs for phishing attempts. In this case, the email actually contains a phishing link and our messaging service can be placed on blacklists by specific email hosting providers, which can cause problems for many other customers.

However, there is always a solution, but it might be more complex than it seems at first glance. We will try to address this improvement and find a solution to make messages more usable with this information.

[CraigF 0]

Thanks for explaining that, igi008, I see the challenge now. Perhaps the URLs could be deconstructed in some fashion so they wouldn't be perceived as a web link. I look forward to seeing the solution you come up with.