Every now and then, we are approached at Support by customers asking why such an event happens. It turns out that in most cases the blocked message was picked up by Message Reputation (which is part of the Sender Authentication policy within MEG).

The most puzzling aspect of this, to most people, is the fact that a message that has the same content as that which was delivered to others, gets blocked for some users! Why?


Before tackling this question, let us first understand a bit more about Message Reputation.


Global Threat Intelligence (GTI) message reputation has been incorporated into McAfee networked products (including Email Gateway) for some time. It makes use of factors such as spam-sending patterns and IP behaviour to determine the likelihood that a given message is malicious (spam, malware, etc.)


The score is based not only on collective intelligence and analysis by McAfee Labs, but also on correlation of cross-vector intelligence from file, web, and network threat data. The local McAfee product — such as Email Gateway — uses the score to determine action based on local policy.


When it comes to MEG and its policy enforcement of the message reputation, the following components of a given message are taken into account:


  • Source IP address
  • The HELO/EHLO command from the sending mail server
  • Sender mail address
  • E-mail recipient
  • E-mail subject
  • Message metadata


NOTE: No message details are ever sent to the McAfee GTI cloud, what MEG submits is a hash that is used to identify the individual message


Knowing what components of a message affect its reputation and resulting score, we can list some scenarios where a message sent to multiple recipients might trigger a Message Reputation event for some of these recipients but not for others:


  • Same mail content sent from different source mail servers (a mail cluster, for example)
  • The e-mail sender address is different for each message
  • The subject may be changed from message to message
  • Slight changes to the email body, which result in a different message hash


These variations explain most cases where a message is allowed through for most recipients but not for a few.


So now that we know why it may happen, what can the e-mail administrator do to mitigate this behaviour, especially where a message was expected to be delivered?


The first step would be to report the purported false positive event. This can be easily done by following our Knowledge Base article KB72091 - Troubleshooting false positives.


The only problem with this approach is that, depending on the mail volumes being processed by MEG and the amount of messages blocked by reputation, is the resulting amount of manual submissions required. It also does not help that the particular occurrence does not leave a quarantined item that the administrator could release to the end user (there is no option to quarantine items that fail sender authentication on MEG).


There is a way to work around this, however. Message reputation scores not only affect the sender authentication policy, but they also trigger certain spam signatures. MEG has some spam definitions based on message reputation scores, adding a number of points to the message spam score based on the reputation score. There are over 150 such definitions in the MEG rule base.


This gives the administrator the option to change the behaviour of MEG for message reputation events, when it is perceived too many messages that are likely to be genuine end up being blocked. It is possible to change the message reputation policy action to Allow (Monitor) instead of a Block action. The event itself is still logged as normally so the administrator will still be able to check the message hash and use it to report a possible false positive.


The actual enforcement, in this scenario, would be taken at the spam policy level. The message reputation score will now be used in relation to triggering spam signatures, and different amounts of points are added up to the spam score depending on the message reputation score received from the GTI cloud lookup. A couple of further actions are required to ensure a spam policy is effective and can be changed to a level where the amount of false positives and/or false negatives are minimised:


    1. Ensure that a spam report is added to all messages (a quick reference on how to do this can be found on this blog post)

    2. Tweak the score options so adequate levels of quarantine and straight drops take place

Enabling the spam report as mentioned above helps is in that it not only gives McAfee Labs valuable information in case a message needs to be reported as a false positive or negative, but it also allows the MEG administrator to understand what scoring levels are adequate for the environment being protected.


Additionally, in the spam policy, the administrator has the additional flexibility of being able to quarantine a message within a certain spam score threshold, so an user can choose to release the message when they are expecting it, or the administrator can use the quarantined content on a submission to McAfee.


In a future article, I shall be discussing how to use other features of the Sender Authentication policy on MEG, and how to use score-based actions there (do not confuse with spam scores as these are separate metrics).


Here is a list of some useful Knowledge Base Articles that provide more insight into the Global Threat Intelligence functionality and some basic troubleshooting steps.


KB74230 - Global Threat Intelligence Technology - Services Overview

KB72970 - Open ports required for the EWS/MEG 7.x Appliance

KB62754 - FAQs for Email Gateway and Email and Web Security