OpenText product name changes coming to the community soon! Learn more.

Wikis - Page

Knowledge Document: Best Practices for Spam Control

0 Likes

Environment:
Secure Messaging Gateway (SMG) 7

Situation:
What are some best practices to help block more spam?

Resolution:
If a lot of spam is getting through, here are a few helpful Tips:

    A) Make sure SMG is set up optimally to block spam. This can be done on the Policy level as well as the Connection
    Drop level.

        1) Policy Level: On the Inbound Mail Filter Policy (or whatever it was named), make sure you have the follow nodes
        on the workbench and that they are either linked to the Spam Filter Group, which is linked to the Message Block
        node, or they are directly linked to the Message Block node. You can click on the icon on the left of each node to
        edit them.


            a) Anti-Spam - Confirmed Spam and Bulk Mail are on by default. If you want to strengthen what is blocked you
            can enable Valid Bulk Mail. Keep in mind that you will see some false positives with this.


            b) SURBL - The default free SURBL server is multi.surbl.org.  Additional SURBL servers can be added here.
           
           
            c) RBL - There are two ways to scan for RBL, connection drop and/or policy level. This is where you can change
            the settings for the policy level. The two default FREE (recommended) RBL servers are sbl-xbl.spamhaus.org
            and bl.spamcop.net. (See below on how to set up RBL on connection drop level).
           
           
            d) SPF (Sender Policy Framework) - This is not enabled with the default wizard, but highly recommend to help
            block spoofed messages. It's recommended to add this to the Spam Filter Group, but not required. To add it to
            the Spam Filter Group drag the green dot on the Spam Filter Group to the right and let go. The menu for filters
            should open up. Choose SPF. Save changes.  (See below on how to set up SPF on connection drop level).

                       
            e) IP Reputation -This is enabled by default on the connection drop level (recommended to take advantage of IP
            reputations grey listing - ipreptempfail). To add on the policy level, do the same as above for adding SPF, only
            choose IP Reputation.
           
            
            Note: If an exception is needed for one of these events an email address exception node can be
            added to either the spam filter group or the node itself, if it's not part of the group.

        2) Connection Drop level: Under Module Management | Interfaces | SMTP Interface Manager | SMTP Interface |
        Connection Drop Services the following can be enabled: 
       
            a)  RBL - If connection dropping for RBL is desired, the recommended settings are as seen in the screenshot
            below, however they can be changed to meet the companies needs:
           
            

            b) IP Reputation -  If connection drop for IP Reputation is desired (recommended), the recommended settings
            are as seen in the screenshot below, however they can be changed to meet the companies needs. 4xx on IP
            reputation tmpfail is when it fires on IP reputation's global greylist. This gives the sending server a 4xx response
            which means to try again later. It helps deter spammers, since they won't usually retry sending the message.
           
            
            c) SPF - Sender Policy Framework. If connection dropping for SPF is desired, the recommended settings are as
            seen in the screenshot below, however they can be changed to meet the companies needs:
           
           
            Note: If an exception is needed for a connection drop event, the sending server's IP can be added to
            Relay/Host Protection (section right above connection drop services) checking the Skip Conn. Tests
            box ONLY.
           
    B) If the recommended settings are already set up and a lot of spam is still getting through. check to see if there
    is an exception allowing them in. The easiest way to do this is to look the message up in Message Tracker,
    click on the message and open Scan Engine Details | Filters, to see if it fired on a filter. If it fired on an
    exception, Message tracker will still show the events that it would have been blocked by if the exception wasn't
    in place.
   
    If it's found that a spam that got through and did fire on a filter then review your exceptions and/or whitelists and adjust
    them accordingly.

    Keep in mind that it is normal to see some spam get through. This spam is called zero day spam.They are
    new spam that don't have a definition file created yet to block them.

    C) If it's found that SMG is set up optimally and it just didn't fire on any of the filters, then there are a couple of
    different options to take:

        1) Add a new filter to block the message by IP, From email address, Subject, Message body, etc.

        Once it's decided, what type of filter to block these with, add that node to the Inbound Mail Filter Policy workbench
        and edit it accordingly. Make sure it gets attached to the Message Block and/or Quarantine nodes. The example
        below is for a Subject Filter:
           
        2) Spam messages that did not fire on the Anti-spam event can be submitted to the servers that do the spam
        scanning. This is called Spam Reporting. If this is enabled, it will add a string with a link, at the bottom of all
        incoming email. The end user can click on the link in submit these as spam. Here is a LINK to the manual with
        instructions on how to enable this.

        NOTE: Usually, by the time these are reported as spam there is already a definition file to block these
        and the users are getting different spam by then.

Access article on the support portal here

Labels:

How To-Best Practice
Comment List
Related
Recommended