SLV

Ad. "variable something like %HeaderFromDisplayName%": it's definitely doable.
Ad. "Increase or Decrease SCL value": that's also doable, we can see the added value of such rule action.

Hello,
the environment variable you mentioned should already work. Maybe the documentation hasn't been updated, but this is the list of currently supported macros (case insensitive):
%ENVELOPESENDER%
%ENVELOPEDOMAIN%
%FROMADDRESS%
%FROMDOMAIN%
%REPLYTOADDRESS%
%REPLYTODOMAIN%

Ad #2 and #3 - will look at that.

Ad #4 - all conditions should have a way how to define them also as a negation, i.e. "is" vs "is not", "contain" vs "doesn't contain" etc... Do you have some example where you can't define the rule now in a way that you want?

Ad %FROMADDRESS%: we will add all missing expandable macros to rule actions in the upcoming feature release.
Ad. Exceptions for conditions in rules: we track this feature in our backlog. It didn't have a very high priority compared to other requirements, as there is a workaround available for most cases and we didn't want to overcomplicate the current design of rules. It's possible we will re-prioritize it again in the future.
Ad. Infected status for attachments blocked by rules - we are aware of this situation and are analyzing possible solutions.

Hi, 
Ad. Internal: messages are consider as internal if the SMTP connection is not marked as external by Exchange server, or when the email comes from the internal mailbox, or when is submitted via local pickup.
Ad. Outgoing: this is based on the email recipients categories. EMSX checks all recipients of the email to determine whether they are located in the same organization, in different organization, or are marked by Exchange as external.

Hi, when there is a limit on number of IP addresses from Received headers set by user, they are counted from the most recent (appears on top). Local IP addresses and addresses on Ignore list are skipped i.e. not counted towards the limit.
Note: besides Received headers, we also acquire the IP address of the connecting server from the SMTP session - this address is always checked against our cloud blacklists/whitelists, independent on whether it is part of Received headers or not. 

Appreciate what you're saying - my understanding is this exploit triggers the Outlook client to initiate an outbound SMB connection via the system process thereby exposing the NTLM hash.
ESET Mail Security is running in the inbound side of Exchange edge transport - before the exploit ever reaches the mailbox, and far before the Outlook client comes into play.