Skip to main content

cloudmark – Cloudmark Authority Module

Last updated March 2020

The Cloudmark Authority module provides message diagnosis via industry-leading spam and phishing protection technology. If you intend to use this module be sure to choose it during installation. For more information see “Installing Additional Packages”.

Note

As of version 3.2, if you are separately updating the Cloudmark cartridge outside of Momentum maintenance releases, the cartridge will need to be manually reinstalled after your Momentum upgrade. Otherwise, no additional update is required.

As of version 3.3, the installer no longer replaces any version of the Cloudmark cartridge manually installed by the customer. If you have manually installed a version of the Cloudmark module, the installer will no longer replace it during an upgrade, even if the version in the Momentum installer is newer than the version currently installed.

When you choose this module during installation the msys-cloudmark-version.os.arch.package_type package is installed. After installation, perform the following steps before starting the ecelerity daemon:

  • Get a license file from Cloudmark

  • Copy this file to /opt/msys/3rdParty/cloudmark/etc/license.cfg

  • Configure the cloudmark module as described below

The first time that ecelerity is loaded after cloudmark is enabled, it may take a significant amount of time for the signatures to be downloaded (on the order of 10 minutes). This download process is initiated by the line download micro-updates before init = yes in the license.cfg file. It is not recommended that this option be disabled.

**Configuration Change. ** This feature is available starting from Momentum 3.0.23.

Momentum version 3.3 uses Cloudmark version 2.0.3.29.3049.1.3.14. Momentum version 3.4 uses the SDK version 3.1.0.13 and the cartridge version is 3051.0.1.18.

Configuration

cloudmark "cloudmark1" {
  MinimumScore = 80
}

# alternative configuration for Lua or Sieve driven operation
cloudmark "cloudmark1" {
  enabled = false
  MinimumScore = 80
}

# alternative configuration for Lua or Sieve driven operation
# note that there is no instance name
cloudmark {
  enabled = false
  MinimumScore = 80
}

To load a module passively, set the enabled option to false. Validation modules can be loaded passively, in which case the validation system will not call the SMTP transaction hooks defined by the module. When a module is loaded in passive mode inbound messages will not be virus scanned unless you explicitly call the appropriate Lua or Sieve action.

Note

As of Momentum version 3.4, this module is a singleton so is declared without an instance name. Also, you must load this module with enabled set to false as shown in Example 14.30, “cloudmark module (as of version 3.4)” and use policy scripts to scan mail. We no longer support having the module scan all messages by default.

MinimumScore

A threshold past which a message will be tagged as spam.

Max_Body_Length

The maximum amount of the body to read for processing (in bytes).

use_wire_rep

**Configuration Change. ** This feature is available starting from Momentum 3.5.x.

If use_wire_rep = true (the default setting), then a dot-stuffed representation of the message is held entirely in memory and can be used as received, rather than loading pieces of the message as needed.

If use_wire_rep = false, then a dot-unstuffed representation of the message will be generated and passed to the module. This rendered version of the message does not include SMTP wrapping (hence, no dot-stuffing or SMTP terminator), but does include any modifications by the policy scripts. Cloudmark may also use any headers added to the message to perform per-customer processing; for example, a customer may want to treat some ESP mail as spam based on the presence of custom headers.

To summarize:

  • use_wire_rep = true: no modifications will be passed to Cloudmark

  • use_wire_rep = false: modifications will be passed to Cloudmark

Cartridge Configuration and Momentum

If the following variables are not set in Cloudmark's cartridge.cfg file, then virus results are not properly returned to Momentum. Use the following settings:

  • favor analysis over speed = yes

  • micro-update signature type = comprehensive_sender_rep.4

You can also use the value comprehensive.4 for micro-update signature type.

Cloudmark Runtime Usage

The Cloudmark engine sets the following validation context parameters:

cmae-score

The Cloudmark authority score for the message, a number between 0 and 100. The higher the number, the more certain the engine is that the mail is spam.

cmae-isspam

If MinimumScore is set, the cmae-isspam is set to true indicating that the engine has determined the message is spam. No action is directly taken on the message; that is left to the user to do using a policy script.

cmae-category

The category assigned to the message by the Cloudmark Authority

cmae-subcategory

The sub-category assigned to the message by the Cloudmark Authority

cmae-rescan

The rescan flag. If this flag is set to ‘1’, the email would benefit from a rescan.

cmae-analysis

The Cloudmark Authority analysis header

cmae-category-desc

The Cloudmark category name

cmae-subcategory-desc

The Cloudmark subcategory name

Use the msys.cloudmark.score Lua function to return a cloudmark score and the msys.cloudmark.analyze Lua function to analyze a message. For more information follow the preceding links.

Use the cloudmark_score Sieve function to return a string containing the numeric score assigned to the active message. For more information see cloudmark_score.

cloudmark Management Using Console Commands

The cloudmark module can be controlled through the ec_console; the following command is available:

14.18.4.1. cloudmark:cloudmark1 version

This command outputs version information for the Cloudmark engine, for example:

10:47:35 /tmp/2025> cloudmark:cloudmark1 version
CmaeVersion = "2.0.3.29"
CmaeCartridgeVersion = "3046.2.0.23"

For instructions on using ec_console see System Console.

Working with the Cloudmark ActiveFilter

This describes how you can configure Momentum to communicate with the Cloudmark ActiveFilter MSI. Fundamentally, it involves configuring Momentum's “maildir – Maildir Delivery Support” module and writing Lua policy that writes specially formatted email messages with XML in the body to the configured maildir. The Cloudmark ActiveFilter MSI consumes this maildir.

**Configuration Change. ** This feature is available starting from Momentum 3.5.4.

maildir "maildir1" {
  basedir = "/var/spool/ecelerity/msi_maildir"
  dirmode = 775
  filemode = 664
  create_users = true
  domain_in_path = true
  all_domains = false
  domains = ( "msi.local" )
}

You must also create the directory that you defined in the basedir option (in the example above, /var/spool/ecelerity/msi_maildir) and give it the same ownership as the owner running the ecelerity process. This will normally be ecuser. Also be sure to create this directory with the same permissions as defined in the dirmode option.

require("msys.core");
require("msys.cloudmark");
require("msys.extended.message");
require("msys.extended.vctx");

local mod = {};

function mod:init()

  msys.cloudmark.set_af_mode_movemsg("Inbox", "Spam", "no"); <a name="cloudmark_af.one"></a> ![1](images/callouts/1.png)
  msys.cloudmark.set_af_msi_address("msi@msi.local");  <a name="cloudmark_af.two"></a> ![2](images/callouts/2.png)

  return 0;
end

function mod:validate_rcptto(msg, s, ac, vctx) <a name="cloudmark_af.three"></a> ![3](images/callouts/3.png)
  local localpart = vctx:get(msys.core.VCTX_MESS, "rcptto_localpart");
  local domain = vctx:get(msys.core.VCTX_MESS, "rcptto_domain");
  msys.cloudmark.add_af_data(localpart .. "@" .. domain,
                             { custom_key = "custom_value" });
  return msys.core.VALIDATE_CONT;
end

function mod:validate_data(msg, ac, vctx)

  -- Set the ActiveFilter score threshold

  local score = msys.cloudmark.score_af(msg, ac, vctx, 90); <a name="cloudmark_af.four"></a> ![4](images/callouts/4.png)
  return msys.core.VALIDATE_CONT;
end

msys.registerModule("af_test", mod);

Discussion

|

|

You must set the AF mode by invoking one of the following functions:

`msys.cloudmark.set_af_mode_movemsg("Inbox", "Spam", "no")`

This sets the AF mode to MOVEMSG. Move messages around based on their status. See See msys.cloudmark.set_af_mode_movemsg

Arguments

  • Inbox folder name.

  • Spam folder name.

  • Unread messages only? Values are "yes" or "no".

`msys.cloudmark.set_af_mode_discard()`

This sets the AF mode to DISCARD. Discard false negatives. No change on false positives. See msys.cloudmark.set_af_mode_discard

`msys.cloudmark.set_af_mode_keep()`

This sets the AF mode to KEEP. Do nothing for any changes. See msys.cloudmark.set_af_mode_keep

| |

|

This is a required function. Set the address for the ActiveFilter MSI Messages to correspond to the maildir defined in the maildir module declaration. See msys.cloudmark.set_af_msi_address

| |

|

This callout implementation is optional. Momentum uses the recipient address by default if this is not set. But this allows you to use custom values such as the actual 'account name' that you may have queried from a directory. See msys.cloudmark.add_af_data

| |

|

Set the ActiveFilter score threshold as part of the fourth argument in this function. If a message is originally marked as "not-spam" and later the message fingerprint exceeds this score, then it will trigger an ActiveFilter update. Similarly, if a message is marked as spam and later is re-classified as "not spam", then ActiveFilter will be updated as well. Note that the latter case is only significant in the MOVEMSG ActiveFilter mode. Why? If you are discarding messages then there is no action to take in the false positive case. See See msys.cloudmark.score_af

|

Was this page helpful?