Customizing SmartActions E-mail Security on the K2 blackpearl Server

This topic details the options for customizing email security. You can configure these settings in the K2HostServer.exe.config file located at "%ProgramFiles%\K2\Host Server\Bin" . Typically email communication happens between authenticated email servers, but since this may not always be the case, the following settings and options need to be considered when configuring SmartActions. The settings are located in the configuration > messageBus > system element, and the details are as follows:

Sample Configuration Code:

<system self="K2:DENALLIX\K2Service" enableListeners="True" ambiguity="true">
		        <security spamSecurity="InternalMail">
						      <authorizedDomains />
						   </security>
			</system>

This main element holds the FQN (fully qualified name) for the account that the K2 server uses to send SmartAction emails.

In most cases the K2 service account's is in the same domain as the server.

system self =” [security label]: [FQN] \ [Service Account Name]”

The enableListeners attribute is enabled by default if Exchange Autodiscover is present on the domain and SmartActions is configured. Changing this Boolean value requires a server restart.

enableListeners="True"

The spamSecurity element leverages the Exchange Spam Confidence Level (SCL) header to reject messages that may not be from authenticated users. To configure the spamSecurity setting its value can either be one of the constants, or an integer.

Setting Description
Internal Mail (SCL -1) Only mail sent to the Exchange server by an authenticated account controlled by the Exchange server receives this SCL rating
Low SCL 0
High SCL 1
Custom value An integer greater than-1
Off Disables the SCL Header rejection feature. No messages will be rejected as the SCL header is being completely ignored.

If a message does not contain an SCL header, and the spamSetting is set to Off, a message with no SCL header can be accepted. If there is no SCL header and the SCL header setting is enabled, the message is rejected.

The authroizedDomains attribute of SmartActions security uses the receive header of the incoming e-mail to verify its authenticity. The received header is used to validate that the mail went through only trusted servers. This requires that the header is completely valid per RFC822 (http://www.ietf.org/rfc/rfc0822.txt). Not all servers are compliant with this standard and some mail servers do not create valid receive headers. This setting also supports the slight variation that Exchange adds.

The following portions of the incoming e-mail are checked if they are present: the 'by', 'from' and 'via' parts are checked. If the element is empty or not present all domains are trusted, meaning this security check is skipped.

Example code:

<authorizedDomains>
						  <add domain="*.denallix.com" />
						  <add domain="*.google.com" />
						  <add domain="*.gmail.com" />
						  <add domain="*.live.com" />
			</authorizedDomains>

Since each process contains a unique serial number, the threat level which may result in a breach of security needs to be determined by your organization. The K2 server only actions process tasks for which there has been an instantiation and the incoming email contains a valid serial number. Unless the K2 server can authenticate the incoming message and associate the serial number with an existing valid process instance, a spoof e-mail has no impact on the operation of the server.

Two examples are shown below offering opposite extremes of security. The first is the most secure and the second is the least secure. Both examples use the fictitious Denallix domain.

High Level SPAM Security Example 

<security spamSecurity="InternalMail">
						  <authorizedDomains>
						    <add domain="*.denallix.com" />
						  </authorizedDomains>
			</security>

The least secure configuration is as follows. This option is not recommended as it completely disables mail security and may expose the network to attacks.

Low Level SPAM Security Example 

<security spamSecurity="Off" />

The K2 environment can be configured to allow for multiple labels to use the same provider or have the same email address across multiple labels.

The following logic applies to this scenario:

  1. Get all the users under all the labels which match the incoming email address.
  2. Alphabetically sort the returned list of users according to their label.
  3. Place the default label first in the list.
  4. Attempt to action the worklist item using the ordered list of FQNs (fully qualified names).

The result is that the user would receive an email notification for each of their email addresses that are found by the K2 server across multiple labels. When they action an email for the any label, no further actions are processed for that task.

Shown below is the ambiguity configuration setting which is set to true by default. When true, the logic above applies. To disable, set the flag to false.

Sample Configuration Code 

<system allowAmbiguity="true" self="K2:DENALLIX\smartactions" enableListeners="true" >
						  <security spamSecurity="Off"/>
			</system>

Ambiguity Tags
<ambiguity> When true, enables support for ambiguous environments where there are two labels that contain the same user email address.

In order to setup SmartActions in your K2 environment, Exchange Web Services (EWS) is required.