Skip navigation

Email Gateway

11 Posts authored by: tkomabay

We have KB79376 which tells how to apply patches on an ePO managed MEG 7.x Appliance.

 

We will make the process a little bit easier. Updated version of KB79376 will be made available soon. In short, we will have less steps in item #3 in the KB. In this blog post I am introducing the new process.

 

Use the following steps to install a MEG patch .zip file to your MEG Appliance that is managed by ePO:

 

  1. Disable ePO management on the Appliance:

    IMPORTANT: If you apply the patches without disabling the ePO management and Extensions, The console/dashboard may become unresponsive. If this occurs, contact McAfee to arrange a remote session to resolve the issue. See the Related Information section of this article for contact details.
    1. Open the MEG Appliance management console and log in using admin credentials.
    2. Navigate to System, Package Installer, ePO, Settings for ePO Management.
    3. Deselect the Enable ePO management and Allow configuration to be applied from ePO options.
    4. Apply changes.
    5. If you have multiple Appliances, repeat these steps for all of them before moving to the next step.
  2. Install the MEG patch .zip file:
    1. Navigate to System, Component Management, Package Installer, Update From File.
    2. Locate the MEG patch zip file, and click OK.
    3. Click OK to install the patch. The Appliance will reboot.
    4. If you have multiple Appliances, install the patch to the rest before moving to the next step.
  3. Update the ePO Extension for your ePO server:
    1. Open the MEG Appliance management console, and log in using admin credentials.
    2. Click the Resources link located at the top-right of the console.
    3. Click the ePO Extensions link and save the Extension to your local folder.
    4. Click the ePO Help Extensions link and save the Extension to your local folder.
    5. Open the ePO console and log in using admin credentials.
    6. Navigate to Menu, Software, Extensions, Email and Web Gateway.
    7. Click Install Extension.
    8. Locate the ePO Extension file that you downloaded from the MEG Appliance, click OK, and then click OK again.
    9. Locate the ePO Help Extension file that you downloaded from MEG Appliance, click OK, and then click OK again.  
  4. Export the Appliance configuration and import it in the ePO policy catalog:
    1. Open the MEG Appliance management console and log in using admin credentials.
    2. Navigate to System, Component Management, ePO, ePO Server Configuration.
    3. Click Export Appliance Configuration and save it to your local folder.
    4. Open the ePO console and log in using admin credentials.
    5. Navigate to Menu, Policy, Policy Catalog.
    6. Select McAfee Email Gateway 7.x from the Product pull-down menu.
    7. Click Import, locate the exported configuration file, and click OK.
    8. Ensure all the items are selected for import and click OK.
  5. Re-enable ePO management on the Appliance:
    1. Open the MEG Appliance management console and log in using admin credentials.
    2. Navigate to System, Package Installer, ePO, Settings for ePO Management.
    3. Select the Enable ePO management and Allow configuration to be applied from ePO options.
    4. Apply changes.
    5. If you have multiple Appliances, re-enable ePO management for the rest of them.

This blog post refines best practices for anti-spam on McAfee Email Gateway 7.x.

 

Update

Ensure that spam rules and engine are up-to-date. If your appliance is not running on the latest updates, your appliance will not catch the latest spam messages.

 

You can check the current update status under System, Component Management, Update Status in the appliance administrator console. Appliance gets update from our update servers. Ensure to open the following ports on your firewall. See KB72970 for the details.

  • Anti-Spam Engine
    • MEG 7.6.2 and later: on HTTPS TCP 443, outbound to tau.mcafee.com.
    • EWS 5.6, MEG 7.0, MEG 7.5, and MEG 7.6 up to 7.6.1: on FTP TCP 21, outbound to ftp.nai.com. Uses PASV.
  • Anti-Spam Rules and Streaming updates

 

Spam score and report

Set up the appliance to add a spam score and report on all messages. Should you get some spam mail delivered to your mailbox (or false positives), you can provide this mail to our spam team for further review and correction.

 

  1. Navigate to Email, Email Policies, SMTP, Spam.
  2. Choose Yes to enable anti-spam scanning. Else you can inherit from the parent policy in which its anti-spam is enabled.
  3. Choose To all messages for Add a spam score indicator.
  4. Choose To all messages for Attach a spam report.
  5. Click OK.
  6. Apply changes.

 

Score based action

Enable the second score based action with When the spam score is at least 5.0, and make sure to check the box in the And Also box to quarantine the modified version of the message.

 

The default configuration is to mark when score is more than or equal to 5 points, and accept and drop when score is more than or equal to 10 points. The spam team considers any message which receives fewer than 5 points to be legitimate and any message receiving 5 or more points to be spam. Therefore, the default anti-spam scanning configuration could let some spam-like emails delivered. Change anti-spam settings as follows if you would like to block email message which spam score is between 5.0 and 10.0:

 

  1. Navigate to Email, Email Policies, SMTP, Spam.
  2. Ensure to check the second When the spam score is at least, and enter 5.0 to the next text box.
  3. Choose Accept and then drop the data (Block) for its action.
  4. In And also checkboxes list, ensure to check Quarantine modified.
  5. Click OK.
  6. Apply changes.

 

If there is a false positive, in other words legitimate email is being scored too high, you can get a copy of it from quarantine and submit to our spam team.

 

Submission

When legitimate message gets blocked by anti-spam, submit it to the spam team for fixing. When spam message gets through the appliance and delivered, submit it to the spam team for fixing. See KB59415 for additional information on submitting messages to our team.

 

McAfee Customer Submission Tool (MCST)

Consider using McAfee Customer Submission Tool (MCST), which is a free plugin for Microsoft Outlook. With MCST, extra buttons or menu entries become available when you read your email. It allows you to perform:

 

  • Submit email samples to McAfee Labs for further analysis
  • Submit email samples to McAfee Quarantine Manager to help prevent further spam
  • Submit unwanted email that was not categorized as spam (or phish)
  • Submit email that was wrongly categorized as spam (or phish)
  • Delete the email message optionally after the submission
  • Add a spam sender's email address to the blacklist to prevent more spam
  • Add a sender's email address to a whitelist to prevent further email from that sender being wrongly categorized as spam or phish
  • Add all the email addresses in your Microsoft Outlook Contacts folder to a whitelist, to prevent emails from known contacts being wrongly categorized as spam or phish
  • Access the tool using the buttons available in the standard toolbar and the entries available in the Actions menu or the ribbon interface in Outlook 2010

 

You can download either the 32 bit or 64 bit version from http://www.mcafee.com/us/downloads/free-tools/customer-submission-tool.aspx. On the right side of the page, there is a box listing "McAfee Customer Submission Instructions" in the eight languages. Clicking on your language will allow you to download a Product Guide and a supplemental Readme.


GTI Message Reputation

 

  • Use GTI message reputation. GTI message reputation identifies a large percentage of spam more quickly than the regular anti-spam scanning, and can help quash spam blasts more quickly.
    1. Navigate to Email, Email Policies, SMTP.
    2. On your inbound email policy group, open Sender Authentication and navigate to Message Reputation tab.
    3. In Higher Detection Threshold, enable McAfee GTI Message Reputation at the higher detection threshold.
    4. Ensure Detection threshold for Higher threshold as Highly suspect.
    5. Choose one of available Block actions from If the sender fails the check list menu.
    6. If your MEG is behind MTA, navigate to Cumulative Score and Other Options tab, ensure to enable Parse the email headers for sender address if behind an MTA option and specify Number of hops to the MTA.
    7. Click OK.
    8. Apply changes

 

  • If your mail server sends email out through your MEG appliance, make sure to have an outbound policy defined by the source IP of your mail server to turn off all sender authentication for outbound email. Below steps show how to create outbound email policy group and disable sender authentication for the outbound policy:
    1. Navigate to Email, Email Policies, SMTP.
    2. Click Add Policy.
    3. Enter policy name for your outbound email policy group.
    4. Choose which policy to inherit settings from.
    5. Choose Outbound for Email direction.
    6. Click Add Rule.
    7. Choose Source IP address for Rule type.
    8. Choose is for Match.
    9. Enter the IP address of your mail server to Value.
    10. Click OK.
    11. Click OK.
    12. On the newly created outbound email policy group, click Sender Authentication.
    13. Choose No for Enable sender authentication for your outbound policy.
    14. Click OK.
    15. Apply changes.

      NOTE: When legitimate message gets blocked by GTI message reputation, refer to KB62754 - Email Gateway/Secure Mail/Email and Web Security: TrustedSource FAQ.

 

  • If the box is behind an MTA and has a hop count set, do NOT use Reject, Close, and Deny(Block) action. Otherwise, the MEG may potentially block the connecting IP address of your onward server when GTI Message Reputation detection triggers.
    • To confirm you have hop count set:
      1. Navigate to Email, Email Policies, Sender Authentication, Cumulative Score and Other Options.
      2. Confirm that Parse the email headers for sender address if behind an MTA option is selected.
    • To configure GTI Message Reputation action:
      1. Navigate to Email, Email Policies, Sender Authentication, Message Reputation.
      2. Ensure that If the sender fails the check is NOT set to Reject, Close, and Deny(Block) for both Higher Detection Threshold and Lower Detection Threshold.
      3. Click OK.
      4. Apply changes.

 

GTI Feedback

Use GTI feedback. GTI feedback submits various metadata about the message to our team so that we can improve the GTI reputations and improve the spam rules as well.

 

  1. Navigate to Email, Email Policies, SMTP, McAfee GTI feedback.
  2. Enable threat feedback.
  3. Click OK.
  4. Apply changes.

 

Logging

If possible, enable all detection events and GTI logging options. This will make GTI related troubleshooting easier.

 

  1. Navigate to System, Logging, Alerting and SNMP, Logging Configuration, SMTP Settings, Detection Events, Advanced.
  2. Scroll down the Override SMTP detection events window and locate McAfee GTI related events. There are a couple of such events.
  3. Select all the McAfee GTI related events.
  4. Click OK.
  5. Apply changes.

 

Recipient Authentication

If possible, enable recipient authentication using LDAP. This will reduce the amount of incoming SMTP DATA phase to the MEG, and help reduce the scanning load on the appliance. See KB76232 for the steps to configure LDAP server and configure the appliance to check the LDAP server for recipient authentication.

 

Quarantine Management
Appliance has onbox quarantine. You can quarantine spam messages to onbox quarantine. It has basic features such as digest message and reporting.


If you want granular control over quarantined items and queues, digest messages, reporting, and black/white list management and/or to consolidate quarantine of multiple McAfee products, consider using off-box quarantine solution - McAfee Quarantine Manager (MQM). MQM runs on Microsoft Windows server platform, gives interactive web GUI, and stores quarantined items using database.
You can download MQM from McAfee Download Site at http://mcafee.com/us/downloads/downloads.aspx. See KB56057 for the details of how to download McAfee products, documentation, security updates, patches, or hotfixes.

If you insert the MEG 7.x ISO CD into the Appliance drive, and you reboot the Appliance to attempt a re-image, you see the following error:

 

Failed to identify the platform in use. Press the enter key to reboot the system

 

Cause
Software installation media has specific hardware requirements. MEG software installer compares the installation requirement with the running appliance hardware information. If the installer does not find matching hardware, or discrepancy from the expected requirement, it raises the error message and stops installation. There are a variety of reasons which can lead to this situation. To resolve it, try checking each solution listed below.

 

Solution (1)
If you begin to see the problem after you change the appliance hardware configuration and/or settings in the BIOS setup, such as changing memory, processor, and RAID disk, it is highly likely that the change caused the problem. Revert the change back and try to reboot the appliance.

 

Solution (2)

Try to boot from the latest available installation ISO image. The latest installation ISO image supports latest available hardware platform. This applies especially repurposing IronMail hardware to run MEG 7.x.

 

Solution (3)
Check your appliance model in the McAfee Product & Technology Support Lifecycle for Appliances to see if your appliance is already EOL:
http://www.mcafee.com/us/support/support-eol-appliances.aspx
McAfee removes support for EOL models from the installer.

 

Solution (4)
MEG 7.5 and later uses a 64-bit operating system, and requires 64-bit compatible hardware. Customers using MEG 7.0 on a virtual machine running on a 32-bit ESX host should continue using MEG 7.0 (KB77795).

 

Solution (5)
There is a known issue specific to Intel-based EG5000 and EG5500 appliance models. Your Intel-based EG5000 or EG5500 appliance displays multiple issues after failing to obtain platform-specific information from the BIOS. KB76748 explains the details of the problem. KB79867 explains how to update the BIOS package. Please read the KB articles and follow the instructions.
IMPORTANT: Do not apply any software patches when the appliance is in this state.

 

Solution (6)
If you have Fail-open Kit, and it is connected to the appliance with serial (RS-232) cable, unplug the serial cable and retry booting from the installer ISO image.

 

Solution (7)
Follow the below instructions to obtain the details for the error:

  1. While you are seeing the "Failed to identify the platform in use. Press the enter key to reboot the system" message, type why then hit enter key. The installer will show the information in the screen.
  2. You can scroll up and down by Shift+PageUp and Shift+PageDown respectively in the console. Take pictures of the each page.
  3. Type saveit then hit enter key. Then follow the onscreen instructions to save the file to USB.
  4. Run IDT tool to obtain diagnostic information. The latest version of the IDT tool is available from the download page. See PD24396 for version 3 usage.

Contact McAfee Technical Support and provide the pictures, the saveit results, and IDT results.

 

NOTE: Below lists typical errors and their resolution for the saveit output in the /logs/ident_log:

Error: /install/variants/mcafee/platform_XXXXXXXX.xml: wrong amount of memory (got ####### want ####### .. #######)
Resolution: Identify bad DIMM and reseat. If reseat does not resolve the problem, replace the DIMM.


Error: /install/variants/mcafee/platform_XXXXXXXX.xml: wrong number of virtual processors (got # want >= # and <= #)
Resolution: Turn hyperthreading On or Off in the BIOS depending on the numeric discrepancy values.


Error: /install/variants/mcafee/platform_XXXXXXXX.xml: missing hard drive sda (runtime sda)
Resolution: Reseat hard drive.

MEG 7.x allows very flexible setting for delivering email over TLS. For example, you can configure your MEG to deliver email over TLS when compliancy scan detects some sensitive information. You can also configure your MEG for when to use TLS and when not to use TLS based on sender (client) domain/subnet and/or next hop (server) domain/subnet.


However, such flexibility also allows you to configure your MEG appliance in a way that TLS delivery settings look conflict. For example, you may wonder how MEG resolves below scenarios:

 

  • What if scanner action results in encryption action that is configured to deliver using TLS, but TLS connections when sending email (gateway is acting as a client) is configured to never use TLS?
  • What if TLS connections when sending email (gateway is acting as a client) has two entries where one entry is never to use TLS for one IP address but another one is always to use TLS for a subnet?


Here is how MEG handles configuration.


1. Encryption policy setting has higher precedence than TLS connections when sending email settings.


In MEG 7.0 and MEG 7.5, If the condition under Email > Email Policies > SMTP > Encryption > When to Encrypt meets, MEG will try to deliver using On-box Encryption Options. If you choose Only when triggered from a scanner action, MEG applies this setting to email messages which hits a scanner action "Deliver message using encryption" in the policy group. If you choose Always, MEG always applies this setting to the email messages that hits the same policy group.

meg75_encryption_policy.png

Fig 1. Screenshot of MEG 7.5 Encryption policy


In MEG 7.6, you have policy based action setting in which you can configure MEG appliance to always deliver message using encryption.

meg76_policy_based_action.png

Fig 2. MEG 7.6 policy based action setting

 

meg76_encryption_policy.png

Fig 3. Screenshot of MEG 7.6 Encryption policy


In On-box Encryption Options under the encryption policy setting, if you deselect S/MIME, PGP, and Secure Web Mail, MEG will use TLS for delivery when policy conditions met. This setting has higher precedence than the TLS connections when sending email (gateway is acting as a client) under Email > Encryption > TLS. Therefore, if scanner action results in encryption action that is configured to deliver using TLS, MEG ignores the entries in TLS connections when sending email settings, and forces to use TLS.


2. TLS never setting has higher precedence in TLS connections when sending email (gateway is acting as a client).


Under Email > Encryption > TLS, you can configure TLS connections when sending email (gateway is acting as a client) per server domain / subnet basis and choose when to use TLS. Available options for when to use TLS are always, never, and when available.


For example, you have the following settings under TLS connections when sending email:
- For 10.10.10.0/24, always use TLS
- For 10.10.10.100, never use TLS
And if delivery lookup falls into 10.10.10.100, MEG will not use TLS.

We update KB76144 - MEG FAQ - as needed. On this short blog post, I would like to introduce some of the changes made recently. For full length of the FAQ, please visit KB76144.

 

An End user has requested the release of some quarantined email items through the quarantine notification digest, but MEG retains it with Release Request Pending status. Why?
MEG on-box quarantine has several queues, such as spam and compliance. Only spam can be released directly to the user. After the user raises a release request for a non-spam/non-viral message, MEG marks it as Release request: Pending . The Administrator has the authority to process the release request from the Message Search by selecting the corresponding quarantined emails and triggering the Release Selected option. 

 

What is the recommended size of the data storage for the MEG virtual appliance?
McAfee recommends 120 GB. Although the minimum configurable size is 40 GB, it can fill up with logs and/or user data, which may result in the logging and/or reporting feature becoming unstable or failing to work properly. Contact McAfee technical support if your disk partition is filling and you experience instability with your virtual appliance installation.

IMPORTANT: After the Appliance is installed, the disk size cannot be changed. You .img” must define the size of the data storage disk during installation.

 

Can I configure a configuration push on the cluster master Appliance to push to the cluster failover Appliance and cluster scanner Appliances?
No. See KB82172   for full details.

IMPORTANT: Do not enable the configuration push feature among cluster member Appliances.

MEG provides very easy-to-setup appliance clustering feature which provides high availability and load balancing among the cluster member appliances. Once you enable appliance clustering (System, System Administration, Cluster Management, Cluster Mode), the clustering subsystem automatically synchronizes configuration and policy settings among the cluster member appliances. It also synchronizes anti-virus DAT and URL filtering database so that you can save network load.


Appliance cluster gives a lot of benefits, but there are something that you need to be careful. Today I introduce two very important points.


1. Do not enable configuration push feature among cluster member appliances.


The configuration push feature (System, System Administration, Configuration Push) uses API over HTTPS to push the configuration from one Appliance to the other listed devices.


On the other hand, the clustering subsystem automatically synchronizes settings among cluster members over TFTP.


If you enable configuration push between the cluster member appliances, configuration changes from two different channels can collide resulting in race condition or damaged back end configuration and your Appliance will become unstable. 


If you happened to enable configuration push among the cluster member appliances, please refer to KB82172 and take remediation actions.


2. Use MQM.


You can choose to use on-box quarantine or off-box McAfee Quarantine Manager (MQM) service for quarantining emails. On the appliance cluster, use MQM.


MQM can handle very large amount of quarantined items as compared to the MEG on-box quarantine. MQM uses MySQL or Microsoft SQL Server database for quarantine. It's scalable and efficient. MQM also provides granular configuration on the quarantine queues.


MEG has feature to save quarantined emails, but does not have restoring option. To illustrate, imagine your appliance cluster consists of cluster master appliance and cluster failover appliance, and scanning is enabled on both of them. If you are using on-box quarantine in this setup, and your master appliance has hardware failure, you will lose quarantined emails. On the other hand, you can configure database backup tasks on MQM database, and restore it when disaster recovery.


For the details of McAfee Quarantine Manager, see its product guide. The latest MQM version is 7.0.1 at the time of this blog post. We strongly recommend to install MQM 7.0.1 Rollup 1 (PD25180) on top of MQM 7.0.1.

When your MEG delivers email to next hop in clear text, and you are troubleshooting SMTP connection to the next hop server, you can run "telnet <target.SMTP.server.address> 25" on the MEG shell (command prompt) and issue some SMTP commands such as EHLO and QUIT. If the target server returns SMTP response code like 250 back against your commands, then the SMTP connection is working somehow.

 

However, when you expect your MEG to deliver email to next hop over TLS, telnet command will not suffice because TLS negotiation phase after STARTTLS requires exchanging binary data. For that particular purpose, you can use "openssl s_client" command instead. Below gives its typical usage:

 

openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp

 

The command will establish TCP connection to the target SMTP server address on given port, exchange initial EHLO command and STARTTLS command on the SMTP connection, exchange TLS handshake messages and certificates, then prompt you over TLS encrypted channel. Your input to this prompt will be transferred to the target SMTP server over the TLS channel, and the target SMTP server will respond you back over the TLS channel. The prompt looks like below:

 

CONNECTED(00000003)
.. (skip) ..
---
250 OK

 

Now that you can enter SMTP commands such as EHLO, MAIL, and RCPT. The target SMTP server will respond back to you with SMTP response code, such as 250 or 452. If you want finish testing it, enter QUIT or any phrase beginning with q.

 

In case you see the "250 OK" message after successful TLS negotiation but typing SMTP commands gives no response back from the server then eventually it shows like "451 4.7.0 Timeout waiting for client input" then try the below command instead:

 

openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf

 

The only difference is -crlf option.

 

The openssl s_client command can be used for identifying which SSL/TLS version does the target SMTP server accept:

 

just use SSLv2: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -ssl2
just use SSLv3: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -ssl3
just use TLSv1: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -tls1
just use TLSv1.1: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -tls1_1
just use TLSv1.2: openssl s_client -connect <target.SMTP.server.address>:<port> -starttls smtp -crlf -tls1_2

 

Take SSLv2 for example, if you don't receive ---250 OK then you can assume that the target server does not accept SSLv2. In such case, you can disable SSLv2 by following KB76671, or install the following MEG patch to your appliance to disable SSLv2 (see KB79384):

 

  • MEG 7.6: 7.6.2 and later
  • MEG 7.5: 7.5.2 and later
  • MEG 7.0: 7.0.4 and later

 

The same applies to TLSv1.2. You can identify whether or not the next hop SMTP server accepts TLSv1.2, then take necessary steps as outlined in KB78818 to disable TLSv1.2.

 

Now that you can identify the expected behavior of the target SMTP server on TLS. Then you can compare it with the network traffic capture of the MEG appliance while it is trying to deliver email to the target SMTP server.

Bounce Address Tag Validation (BATV) enables your MEG appliance to ignore backscatter email message.

 

Quoting backscatter from KB69704 - Glossary of technical terms:

When spam or phishing messages use forged (spoofed) source addresses belonging to a company's domain, that company can be flooded with email bounces known as backscatter if the fraudulent email's recipient addresses do not exist. In the worst cases, a mail loop occurs when the message is bounced to a non-existent sender address.

 

 

The appliance can attach an encrypted digital signature (or tag) to the SMTP MAIL FROM address on every outgoing email message. When a bounced email arrives, the appliance searches for the digital signature, and rejects any message that has no digital signature or has an invalid digital signature.


BATV Configuration
You can enable BATV in the appliance GUI, Email, Email Configuration, Receiving Email, Bounce Address Tag Validation.

 

There are several configurable items. To enable BATV, simply check Enable bounce address tag validation option and apply the change. Your MEG appliance will populate the default BATV options - reject when validation fails, 7 days life time, and randomly generated signature seed. Below table shows the details about each option.

 

OptionDefinition
Enable bounce address tag validationSelect to configure BATV on your appliance.
Signature lifetimeSpecifies how long the signature seed will be used to sign outgoing email. Mail servers typically try to deliver mail for up to four days. McAfee recommend a value of 4–7 days.
Signature seed

Specifies a seed for signing the sender's address.

Use only letters, numbers and space characters. The acceptable key length is 4–64 characters. Type a seed that is not easy to guess.

GenerateWhen clicked, generates a signature seed that has 20 random letters and numbers. You can use this method instead of typing your own signature seed.
Protocol preset (available in MEG 7.5 and later)Select a Protocol preset to allow you to configure per-policy actions for BATV on your appliance.
When validation fails

Specifies how the appliance must handle each invalid bounced message. The available options are:

• Allow through 

• Reject 

 

BATV Behavior
Let's see how the appliance adds BATV tag and validates it.

 

Tagging
The appliance uses Simple Private Signature (prvs) scheme when BATV is enabled. If the original <local-part> is <someone@test.local>, the BATV <local-part> in prvs scheme will look like <prvs=KDDDSSSSSS=someone@test.local> where KDDD represents 4 digits and SSSSSS represents 6 hexadecimal letters.

 

If you enable SMTP Conversation Logging feature which I introduced in my last blog post, you can verify it on MAIL FROM in DELIVERY section. The attached screenshot below shows the conversation logging which records MEG appliance sent MAIL FROM:<prvs=0149c9be41=foobar@test.local> to the next hop MTA.

trim-conv_log.PNG

 

Validation
When the appliance receives null sender in SMTP MAIL FROM command and if BATV is enabled, the appliance validates RCPT TO email address. If it does not have valid prvs tag or invalid tag, the appliance will take BATV invalid action.

 

The attached screenshot below is from my Wireshark network analyzer. There are two groups of SMTP conversation, where the first group is for validation failure case, whereas the second group is for successful validation case.

trim-validation.PNG

 

In the first case, the conversation went in the following order where you can verify that RCPT does not have BATV prvs tag hence MEG returned 550 error code and rejected it:
Client sent to MEG: MAIL FROM: <>
MEG sent to client: 250 Requested mail action okay, completed.
Client sent to MEG: RCPT TO: <foobar@test.local>
MEG sent to client: 550 Invalid tag value.

 

In the second case, the conversation went in the following order where you can verify that RCPT does have BATV prvs tag hence MEG returned 250 success code and accepted it:
Client sent to MEG: MAIL FROM: <>
MEG sent to client: 250 Requested mail action okay, completed.
Client sent to MEG: RCPT TO: <prvs=0149c9be41=foobar@test.local>
MEG sent to client: 250 Requested mail action okay, completed.

 

During the above test, I manually typed the SMTP commands and sent QUIT after successful BATV validation. In a real MEG setup, client would send DATA command after successful BATV validation.

 

Note that BATV prvs tag value changes everyday and you have signature lifetime setting.

You may sometimes experience that your MEG appliance blocks your email. This blog post explains how to identify what configuration and/or policy setting is blocking your email by using

Message Search feature and Email Reports feature on your MEG appliance.

 

SMTP Conversation

Before digging into MEG features, we need to understand how email transport is done behind the scene. When you send an email, your email software sends your message to your email server, then the server forwards it to destination email server (or next hop MTA, depending on your network design). In the Internet, email message across organizations is typically transferred over SMTP (Simple Mail Transfer Protocol) communication.

 

The below list shows very simple SMTP conversation between an SMTP client and server, where message from the server to the client is denoted as :S, and message from the client to the server is denoted as :C.

 

220 scmgateway.tomo.local EGVA/SMTP Ready.:S
HELO test:C
250 Requested mail action okay, completed.:S

MAIL FROM: <tomo@some.domain>

:C
250 Requested mail action okay, completed.:S

RCPT TO: <tomo@tomo.local>

:C
250 Requested mail action okay, completed.:S
DATA:C
354 Enter mail, end with "." on a line by itself.:S

From: <tomo@some.domain>

:C

To: <tomo@tomo.local>

:C
Subject: Test:C
Date: Mon, 10 Feb 2014 09:09:09 +0900:C
:C
Test:C
Message:C
.:C
250 Requested mail action okay, completed.:S
QUIT:C

 

Because MEG receives email message, scans it, and delivers it to the next hop, MEG initially comes as an SMTP server when handling an email message.

 

MAIL FROM, RCPT TO, and DATA Phases

The client transfers email message after the DATA command. In other words, email message content can only be noticed by your MEG appliance after the client sends DATA command. It characterizes SMTP conversation, and affects how the MEG reporting features are oriented in Message Search and Email Report features.

 

SMTP conversation which goes after DATA phase can be searched from both Message Search and Email Reports. However, some SMTP conversations can be rejected and closed before reaching to the DATA command. You cannot find traces for such short SMTP conversations using Message Search; Message Search can only show email messages that have passed DATA phase.

 

MEG appliance has several features to restrict rogue SMTP conversations at MAIL FROM phase and RCPT TO phase. For example, Permit Sender feature under Email, Email Configuration, Receiving Email, Permit and Deny Lists, Permitted and blocked senders takes effect at MAIL FROM phase, whereas Anti-relay feature under Email, Email Configuration, Receiving Email, Anti-Relay Settings takes effect at RCPT TO phase. You can use Email Reports Detail View to troubleshoot those features that take effect at MAIL FROM and RCPT TO phases.

 

For the complete list of the processors that are associated with SMTP commands, please refer to the Life of an email message section in McAfee® Email Gateway Appliances Administrators Guide.

 

Message Search feature and Email Reports Detail View feature

You can search for email message and/or SMTP conversation for a variety of search criteria, for example date and time, source IP address, and policy. Search for your email message in Message Search and/or Email Reports Detail View, then identify which setting has blocked your email. I would suggest you to firstly check Message Search then Email Reports Detail View because it is easy to search for email messages with subject of your email message in Message Search (recall that email subject only appears after DATA command).

 

NOTE: Message Search gives almost real time result of the processed email messages, whereas Email Reports reflects the event information in a couple of minutes delay due to event information caching and bulk update in the appliance backend.

 

Message Search screenshot

messagesearch.png


Email Reports Detail View screenshot

emailreport.png


Conversation Logging

MEG 7.x has SMTP Conversation Logging feature. It logs SMTP conversations allowing you to see how an email has been processed. You can view logs for individual messages in Message Search.

On MEG 7.5 and onwards, Conversation Logging is enabled by default. Please note that on MEG 7.0 enabling Conversation Logging adversely affects performance.

 

To view conversation log for an email message, select a row in the Message Search results, then click View Conversation Log button. You can see what configuration has had particular action result, what SMTP scanning policy group has been applied, and scanner results in chronological order.

 

Screenshot for selecting one row in Message Search

tooseeconvlog.png

 

Screenshot for a conversation log

convlog.png
Here, in the conversation log screenshot, we can see the SMTP conversation including MAIL FROM, RCPT TO and DATA, the MEG scanned the message using Default SMTP policy group, no detection from anti-virus scan, spam score is 7.3 which is relatively high.

MEG appliance has compliance scanning feature which allows you to block email message based on detection against particular text string in the email message.

 

For example, if you want to block outgoing email messages containing Social Security Number, you can create SMTP policy group for outbound email then configure its Compliance policy to block it.

 

  1. Create SMTP policy group:

    NOTE: If you already have SMTP policy group for outbound emails, skip to process number 2. Configure Compliance policy setting.

    NOTE: This example assumes that your outbound emails are sent from local IP address range 10.0.0.0/8 and your email address is like John_Smith@example.local. Change these addresses to suit with your environment when you configure your appliance.
    1. Open the appliance management console.
    2. Navigate to Email, Email Policies, Select a protocol: SMTP.
    3. Click Add Policy button.
    4. Enter policy name, for example Outbound Compliance Check.
    5. Change Email direction to Outbound.
    6. Change Match logic to Match all of the following rules.
    7. Click Add Rule.
    8. Configure the rule as below, then click OK.
      Rule type: Source IP address
      Match: is in
      Value: 10.0.0.0/8
    9. Click Add Rule.
    10. Configure the rule as below, then click OK.
      Rule type: Recipient email address
      Match: is not like
      Value: *@example.local
    11. Click OK

 

  1. Configure Compliance policy setting:
    1. Open the appliance management console.
    2. Navigate to Email, Email Policies, Select a protocol: SMTP.
    3. Identify the row of your policy group for outbound emails.
    4. Click Compliance.
    5. Choose Yes for Enable compliance for <your_policy_name>.
    6. Click Create new rule.
    7. Enter rule name, for example SSN Detection, then click Next.
    8. For Dictionaries to include, enter Social to Search, click Search dictionary names icon.
    9. Check Social Security Number, then click Next.
    10. For Dictionaries to be excluded, do not check anything, then click Next.
    11. For If the compliance rule is triggered, choose one of the Block action, for example Refuse the data and return an error code.
    12. For And also, you can configure additional actions, such as to deliver notification email to the sender of the original email or to deliver a notification email to administrator. Check the item(s) per your requirement.
    13. Click Finish to the Rule Creation Wizard.

      NOTE: Appliance has a template rule for Social Security Number detection. To use the template, click Create new rule from template, find North America PII - Social Security Number Violations, then proceed the Rule Creation Wizard.
    14. Click OK for the Compliance Settings.
    15. Apply changes.

 

Then, you can send a test email to your external mail box such as Gmail over the MEG appliance. You can use the test string "SSN 111-22-3333" in either message body or subject. After sending the test email, you can open Message Search to verify the results.

 

You can create your own dictionary and term to meet with your requirement.

 

  1. Create your dictionary and term:
    1. Open the appliance management console.
    2. Navigate to Email, DLP and Compliance, Compliance Dictionaries.
    3. Click Add Dictionary button in Dictionary List area.
    4. Name your dictionary, put description as needed, choose language whether it is English or not, and choose match type whether it is simple string match dictionary or regular expression dictionary.
    5. Click OK.
    6. Click your new dictionary to highlight it in the Dictionary List.
    7. Beneath the Dictionary List, locate Dictionary details for your new dictionary.
    8. Click Edit icon for the New term, change the term to suit with your required term.
    9. Enable Case sensitive, Wildcard, Starts with, and Ends with options as needed.
    10. Click OK.
    11. Add terms and conditions based on your need.
    12. Apply changes.

 

Now that you can use your own dictionary with your own term settings in the compliance policy settings.

 

Compliance dictionary and term have a lot of options for customizing matching logic. For the details, open online help by clicking the question icon located at the top right corner of the appliance management console, then navigate to Contents, Overview of Email menu, DLP and Compliance overview, Compliance Dictionaries.

This is a patch season for your MEG appliance. We had MEG 7.5.1 (patch 1 for MEG 7.5) posted to our download site on October 14, 2013. Currently MEG 7.0.4 (patch 4 for MEG 7.0) is underway and expected to be released within a couple of weeks. This week I'd like to introduce a special consideration which you'll need to be careful when installing patch to your MEG appliance that is managed by ePO.

 

You can install the MEG patch from System, Component Management, Package Installer, Update From File. Before you install the MEG patch to an Appliance that is managed by ePO, you must disable ePO management and update the Extensions on your ePO server. Otherwise, you may encounter unexpected behavior on your Appliance (for example, the management console becomes unavailable).

 

The reason why we need to follow the process is to avoid mismatch in ePO extension and appliance configuration file structure between MEG appliance and ePO server. MEG appliance holds its configuration as XML files in the backend. MEG patch may add and/or change the structure and/or value of the XML configuration files in order to introduce enhancement and/or fix. MEG patch may contain updated ePO extensions that is aligned to the enhancement/fix. If XML file structure and ePO extension are not updated in sync among MEG appliance and ePO server, ePO would push configuration to the MEG appliance with wrong format and/or value, which could result in various unexpected behavior.

 

The process for installing MEG patch to ePO managed MEG appliance is outlined below:

  1. Disable ePO management on the appliance.
  2. Install the MEG patch.
  3. Update the ePO extension for your ePO server.
  4. Export the appliance configuration and import it in the ePO policy catalog.
  5. Re-enable ePO management on the appliance.

 

We prepared KB79376 for the details of this process. Patch release notes for MEG 7.5.1, MEG 7.0.4, and their successors will have a hyperlink to KB79376 and explicitly warn. Please see KB79376 before installing patch to your MEG appliance that is managed by ePO.

 

Please also see KB79376 if you happened to install MEG patch to your ePO managed MEG appliances, which resulted in your MEG appliance console/dashboard being unresponsive. Then contact McAfee to arrange a remote session to resolve the issue accordingly.

Filter Blog

By date:
By tag: