The McAfee Email Gateway provides the following checks as part of e-mail sender authentication for any given email policy:


  • GTI (Global Thread Intelligence / previously known as TrustedSource)
  • RBL (Real-Time Blackhole List)
  • SPF (Sender Policy Framework)
  • SenderID (SPF 2.0 / PRA - Purported Responsible Address
  • DKIM (Domain Keys Identified Mail)
  • FCrDNS (Forward-confirmed reverse DNS)


I will not be covering the details of what each of these does as they are either well-known standards or are covered elsewhere in this same blog (particularly true for the GTI feature).


One thing that is true about all of these methods is that not a single of them will always be 100% effective at preventing spam.  For a number of reasons outside the scope of this article, in real life we will always see one or the other cause issues with false positives ,or will simply not seem to work at all (too many missed spam messages allowed through).


Say, for instance, you have chosen to enable the GTI feature on MEG, and found that too many genuine senders get blocked by the policy. Upon checking the blocked messages you are able to determine that none of the other scanners would have blocked them.


How can you leverage this knowledge and apply it to the spam policy, so as to avert this issue of false positives?


By using score-based actions, you can assign different weights to each feature, and use this to determine whether a message should be blocked due to failing sender authentication. I will provide a practical example here.


For this example I have chosen to have the following logic applied (bear in mind this is only an illustration, not a recommendation as such - understanding of particular requirements is needed in order to recommend a particular configuration):


  1. An RBL match will result in an outright rejection; no other checks required
  2. A GTI or SPF check failure will result in a rejection if any of the other checks fails
  3. DKIM failure will only result in a rejection if SenderID and FCrDNS also fail
  4. A SenderID and/or FCrDNS failure are allowed through but the event is logged


In order to implement this logic, the administrator can configure MEG to trigger the cumulative score action at a threshold of 40, and configure each individual scanner with the following values:


  • GTI: 30
  • RBL: Reject, close and deny (no score action)
  • SPF: 30
  • SenderID: 10
  • DKIM: 20
  • FCrDNS: 10


The above could be changed as desired, obviously depending on the particular requirement. It is also worth noting that this can be customised in a per-policy basis, inbound and outbound.


It is also possible to set MEG in a way that it can take into account the fact that other front-end servers may be in the path of the incoming message, so it can parse the headers and use this data to determine the actual source of the message (see screenshot below).

For example, if MEG receives messages from another anti-spam filter or a cloud service that checks for spam and viruses, it is possible to configure MEG so it looks at the "Received:" header information and find the address of the previous device. It can then carry out the appropriate lookups against the actual source of the message.


Using this feature allows the administrator to fine-tune the MEG policy and make spam mitigation more effective.