reject mails content filter based (regex)

[juliandecker]

How can I reject incoming mails based on a regex?

[Bob Fayne]

When you say reject, do you mean within the SMTP conversation or are you willing to accept the message and drop/bounce it later? if you want to reject during the SMTP conversation there are limited criteria with which you can do that.

1) Sender IP address/hostname

2) Mail from

3) Rcpt to (recipient validation)

Once you allow the sender to get to the Data command and send a body, the ability to use a regex goes way up but a true reject is no longer possible. You will be limited to normal drop/quarantine/bounce options.

Off the top of my head I believe that #1 and #2 above have some ability to use a regex but I would have to verify it to be sure. The appliance does try to allow for regex to be used as much as possible.

#3 pretty much wants LDAP lookups which might allow for some creative globbing but not so much a straight up regex.

[juliandecker]

thank you for your answer.

I'm talking about spam actually so I have to reject it immediately since most of the sender addresses are just spoofed.

[donnylee]

Depending on where you would like to apply the anti-spoofing filter. In my opinion, using message filter is probably the best option. Regex is used when you craft the filter to scan the email address of incoming messages. Generally internal email (same domain name) will be routed internally without going through the ESA, so if there is any incoming mail carrying your domain name that should only be allowed based on sender or sender host, other than these, they are spoofed mails.

The filter will look like below where the filter will scan the mails received from listener called "InboundMail" for their mail-from and from headers string to match @mydomain.com. If any mail is intercepted, the subject line will be added with "POSSIBLE SPOOFED" at the beginning and mail is sent Policy quarantine. Alternatively, you can add extra lines to check senders or sender host (remote-ip) using content dictionary and exempt it from being marked as spoofed. For action, you can change it to drop, bounce or whatever the action you would like to apply to the mail.

AntiSpoof:

if ((recv-listener == "InboundMail") {

      if (mail-from == "(?i)@mydomain\\.com$") OR (header("From") == "(?i)@mydomain\\.com$"){

          strip-header("Subject");

          insert-header("Subject", "$Subject {POSSIBLE SPOOFED}");

          quarantine('Policy');

       }

}

Hope this helps.

-Donny

[Bob Fayne]

Rejecting incoming emails where the envelope sender is in your own domain can help but if you have any roaming users it will likely end up being a problem unless they always connect over VPN. My experience has been that they will often try to use other ways to send email even if just as an expedient.

You absolutely can reject spoofed envelope senders but these are based on basic rules rather than a regex. From the GUI menu select Mail Policies -> Mail Flow Policies and you can edit the settings for each mail flow policy. Each policy has a section at the bottom called "Sender Verification."

You can reject based on three main criteria. The appliance does a DNS lookup on the domain in the envelope sender and can take action based on this.

1) Malformed or partial envelope sender

    Example: Just a username with no domain at all

2) Envelope senders where the domain does not resolve

   DNS returns temporary error. Could be all their DNS servers are unreachable.

   The appliance defaults to a 4xx 'try later' response.

3) Envelope senders where the domain does not exist

    DNS returns NX Domain/Perm fail. Like if the roots say the domain does not exist.

    The appliance defaults to a 5xx "perm fail" response.

I have tried for years to get Cisco/Ironport to add options where the MX resolves to something ridiculous like 127.0.0.1 or 1.1.1.1 but that has never flown since it would involve interpreting a DNS lookup versus just a go/no go result.Even just the three cases there are now can make a huge difference.

Anyway, check the section titled "Sender Verification: Envelope Sender" in the AsyncOS configuration guide.for more information on these settings.

The Advanced Configuration Guide details a fairly new feature (for Ironport) called SMTP Call-Ahead. It can go further by looking up the full email address but make sure that you understand the implications of this as it can result in your mail server being seen as doing excessive lookups and getting blocked, or worse, a DOS attack.