Spam best practices

From MsgServerDocWiki

Jump to: navigation, search

What are current best-practices for Spam detection and prevention?

UPDATE, 2/5/2010: This information has been moved to: http://wikis.sun.com/display/CommSuite/Messaging+Server+Best+Practices+for+Fighting+Email+Spam. Refer to that page from now on.

NOTE: Work in progress - any additions/clarifications/suggestions welcome

Contents

[edit] Overview

Spam detection and prevention is a complex issue with no magical technical answers - despite what anti-spam vendors may be telling you. The best you can hope to achieve is to reduce its impact on your internal users, the organization's email systems and external email recipients.

[edit] Proactive measures to prevent Spam

Prevention is better then cure. To send emails to recipients within your organization - spam or otherwise, the sender must have a list of valid email addresses. If this information is not easily available there is less chance your users will be recipients of spam email.

[edit] Stopping Spam within an organization

The reputation of your organization can be seriously harmed if systems within your organization are found to be a source of Spam email. This can also result in your organization being listed on external blacklists which will prevent other external recipients receiving emails sent by your user-base.

  • Don't be an open relay!
    • You can test to see if your email server is an open relay
    • Sun messaging server is by default configured to not be an open relay.
    • Ensure that only systems within your organization that you trust are listed in the INTERNAL_IP mapping table.
  • Block outgoing email delivery (port-25) connections
    • This will prevent virus & trojan infected systems within your organizations IP range from sending emails directly to external addresses - blocking a significant amount of spam email.
    • Allow only a select number of systems access to send email to external hosts
  • Scan internal emails for Spam (optional)
    • Depending on your user-base (an ISP is vastly different to a corporate organization - threats of disciplinary action usually stop staff in corporations from acting up), it may be appropriate to scan emails for spam and process accordingly (e.g. bounce back to the sender).
    • Make sure you have the appropriate policies in place which allow for this.
  • Scan _all_ emails for viruses
    • Scanning for viruses is 'cheap' from a CPU perspective and can save a lot of I/O
    • Discard (use the jettison keyword which can't be overridden by user-level sieve) emails found to be viruses. The chance of a valid email being virus infected today is extremely slim and the protection this offers during a virus-flood is great.
    • If nothing else use the free ClamAV anti-virus software; Sun Messaging server 6.3 provides a simple to use and integrate ClamAV Plugin.
  • Detect and reject as soon as possible (don't be a source of Spam)
    • Your Sun Messaging Server should be at the edge of your network so as to reject emails before accepting them - this is also a requirement if you intend to enforce RBL checks with Sun Messaging Server.
    • Use the DEFER_GROUP_PROCESSING MTA option of -1 (authorization check before accept for groups) to reject more emails destined for mailing lists/groups (new for 6.3p1)
  • Handle bounce emails in a different channel
  • Enforce client authentication
    • Require SMTP AUTH for all but a select group of trusted email servers.
    • Stops trojans/virus infected systems from sending emails to internal accounts
    • Allows for increased auditing of email delivery which can be useful if tracking down a 'spamming' account.
  • Overquota notifications
    • Reject emails for overquota accounts immediately rather then accepting, queuing and then bouncing (if the user doesn't reduce their quota)
      • Refer to the local.store.overquotastatus configutil parameter (6.2 and above)
  • Bounces (autoreply) for Spam emails
    • Use the "novacation" sieve action to disable autoreply for emails detected as Spam (assumes you have some kind of Spam detection in place).
  • Provide SRS/SPF records
    • If emails don't come from your 'trusted' email servers, then external organizations are able to reject them outright.
    • There are downsides to this approach - such as with forwarding of emails via external sites, and users sending email via their local ISP using their organizations FROM: address.
    • This can help prevent email forgery, which is a very common virus/trojan email mechanism.

[edit] Stopping Spam at the edge

These mechanisms are designed to stop Spam email before the email is accepted. For each technique, you should weigh up the costs (system utilisation, delivery delays, administration maintenance, false-positives) vs. benefits (reduced 'spam' email).

  • Greylisting
    • Technique relies on Spam-clients not keeping a queue for delivery, therefore if the email is initially refused the Spam-client won't reattempt email delivery whereas 'legitimate' email servers will.
    • Has the downside of potentially delaying legitimate emails.
    • Should only be used on tcp_local channel otherwise internal users may complain that their emails get rejected.
    • Messaging Server plugin-based mechanism (5.2 and above)
    • milter-based greylist mechanism (6.3)
  • RBL's
  • Delay mechanism
    • Email clients that "blast" out emails can be detected and rejected by delaying the sending of the initial SMTP banner. If the email-client sends data before the banner is provided, it is not RFC compliant and is most likely a Spam-bot.
  • Lock down mailing lists
    • Mailing lists offer the quickest way to spam a lot of recipients (e.g. a single mail to a mailing list for all your users).
    • Large mailing lists should be locked down to just authenticated senders (mgrpBroadcasterPolicy: SMTP_AUTH_REQUIRED)
    • Other restrictions can be applied such as allowing only certain email addresses (mgrpAllowedBroadcaster/mgrpDisallowedBroadcaster) or email domains (mgrpAllowedDomain/mgrpDisallowedDomain) to post, or even just [Restrict Dynamic Mailing List allow members of the list to post]
  • DNS record verification for senders domain
    • mailfromdnsverify channel keyword can be used to verify that the email domain of the sender at the MAIL FROM: stage is resolvable
    • This technique can help to reduce Spam which uses randomly generated email domains.
    • Reduces chances that email will be accepted that cannot be 'bounced' back to the sender if required.

[edit] Detecting and processing Spam

  • Virus scanning and discarding infected email
    • Messaging server provides a number of methods to integrate anti-virus programs including the conversion channel, aliasdetourhost mechanism, plugins for a number of common anti-virus products, or you can even write your own channel.
    • The freely available ClamAV software can be easily integrated in Messaging Server 6.3 using the libclamav.so plugin, so if money is an issue, this should be used at a minimum.
  • Spam filtering software to detect and action Spam email
    • The freely available SpamAssassin software can be easily integrated in Messaging Server 6.2 and above using the libspamass.so plugin, so if money is an issue, this should be used at a minimum.
    • File into Spam folders
      • Configure an expiry rule to auto-cleanup the Spam folder, reduces storage requirements and decreases quota usage.
    • Discard almost certain Spam (e.g. SpamAssassin emails that get a score of 10 and above). Refer to "To Filter Messages Based on SpamAssassin Score" in the SpamAssassin integration guide for an example on how to filter based on the SpamAssassin Spam score.
Retrieved from "http://msg.wikidoc.info/index.php/Spam_best_practices"
Personal tools