Cisco Email Security Appliance

ESA Spoofed Mail Filtering

Document ID: 117796

Updated: Jun 11, 2014

Contributed by Nasir Shakour, Cisco TAC Engineer.



This document describes a problem that is encountered in the Cisco Email Security Appliance (ESA) when spam and fraudulent email enters into the network. Possible solutions to this problem are also described.



Cisco recommends that you have knowledge of these topics:

  • Cisco ESA
  • AsyncOS

Components Used

The information in this document is based on these hardware and software versions:

  • All versions of Cisco ESA
  • All versions of AsyncOS

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command. 


Fraudsters attempt to impersonate email. When the email impersonates (purports to be from) a member of your company staff, it can be particularly deceptive and has the potential to cause confusion. In an attempt to solve this problem, email administrators might attempt to block inbound mail that appears to originate from within the company (spoofed mail).

It might seem logical that if you block the inbound mail from the Internet that has the company return address in the domain name, it solves the problem. Unfortunately, when you block mail in this way, it can also block legitimate email at the same time. Consider these examples:

  • An employee travels and uses a hotel Internet Service Provider (ISP) that transparently redirects all of the Simple Mail Transfer Protocol (SMTP) traffic to the ISP mail servers. When mail is sent, it might seem that it flows directly through the enterprise SMTP server, but it is actually sent through a third-party SMTP server before it is delivered to the enterprise.

  • An employee subscribes to an email discussion list. When messages are sent to the email list, they are returned to all subscribers, apparently from the originator. 

  • An external system is used in order to monitor performance or reachability of externally-visible devices. When an alert occurs, the email has the company domain name in the return address. Third-party service providers, such as WebEx, do this fairly frequently.

  • Because of a temporary network configuration error, mail from inside of the company is sent via the inbound listener, rather than the outbound listener.

  • Someone outside of the company receives a message that they forward back into the company with a Mail User Agent (MUA) that uses new header lines rather than the original header.

  • An Internet-based application, such as the Federal Express shipping pages or the Yahoo email this article page, creates legitimate mail with a return address that points back to the company.  The mail is legitimate and has a source address from inside of the company, but it does not originate from inside.

These examples show that if you block inbound mail based on the domain information, it can result in false positives.


This section describes the recommended actions that you should perform in order to solve this problem.

Apply Filters

In order to avoid the loss of legitimate email messages, do not block the inbound mail based on the domain information. Instead, you can tag the subject line of these types of messages as they enter the network, which indicates to the recipient that the messages are potentially forged. This can be accomplished either with message filters or with content filters.

The basic strategy for these filters is to check the backwards-pointed body header lines (the From data is the most important), as well as the RFC 821 Envelope Sender. These header lines are most commonly shown in MUAs and are the ones that are most likely to be forged by a fraudulent person.

The message filter in the next example shows how you can tag messages that are potentially impersonated. This filter performs several actions:

  • If the subject line already has "{Possibly Forged}" in it, then another copy is not added by the filter. This is important when replies are included in the message flow, and a subject line might move through the mail gateway several times before a message thread is complete.

  • This filter searches for the Envelope Sender or the From header that has an address that ends in the domain name It is important to note that the mail-from search is automatically case-insensitive, but the from-header search is not. If the domain name is found in either location, the filter inserts "{Possibly Forged}" at the end of the subject line. 

Here is an example of the filter:


    if ( (recv-listener == "InboundMail")       AND
         (subject != "\\{Possibly Forged\\}$") )
        if (mail-from == "@yourdomain\\.com$") OR
           (header("From") == "(?i)@yourdomain\\.com$")
            insert-header("Subject", "$Subject {Possibly Forged}");

Additional Measures

Because there is no simple way to identify spoofed mail from legitimate mail, there is no way to eliminate the problem entirely. Therefore, Cisco recommends that you enable the IronPort anti-spam scanner (integrated with AsyncOS), which effectively identifies fraudulent mail (phishing) or spam and blocks it positively. The use of this anti-spam scanner, when coupled with the filters described in the previous section, provides the best results without the loss of legitimate email.

If you must identify fraudulent emails that come into your network, then consider the use of the Domain Keys Identified Mail (DKIM) technology; it requires more set up, but it is a good measure against phishing and fraudulent emails. The DKIM technology is fully supported in AsyncOS Versions 5.5 and later.

Note: For more information about message filters, refer to the AsyncOS User Guide on the IronPort Systems support page.

Updated: Jun 11, 2014
Document ID: 117796