Customizing the E-mail Security
Discussed below are some of the options for customizing the e-mail security. These settings are configurable by the K2 Administrator using settings in the K2HostServer.config file. The expectation is that e-mail communication is between authenticated e-mail servers, but since this may not always be the case, the following settings and options need to be considered when configuring K2 SmartActions.
The settings can be located in the configuration > messageBus > system element, and the details are as follows.
 CopySample Configuration Code CS |
|---|
| <system self="K2:DENALLIX\K2Service" enableListeners="false" ambiguity="true"> <security spamSecurity="InternalMail"> <authorizedDomains /> </security> </system> |
A primary consideration for the K2 Administrator is to ensure that the inter K2 Server - Client user e-mail communication remains safe and spoof / spam and phishing proof.
System Self
This main element holds the identity of the FQN for the K2 Server and remains the same unless integrated authentication is not used. Only the SMTP protocol is currently supported for K2 SmartActions and if integrated authentication is used then the FQN is required.
In most cases the K2 Service’s domain account is the same as the internal domain.
| CopyExample Title CS |
|---|
| system self =” [security label]: [FQN] \ [Service Account Name]” |
The listeners are the e-mail servers and Exchange is enabled by default. This element is either true or false. This setting is enabled in the K2 Configuration file and a change in the config file require a server restart.
| CopyExample Title CS |
|---|
|
enableListeners="false" |
spamSecurity
The spamSecurity element leverages the Exchange SCL (Spam Confidence Level) 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 settings are enabled, the message is rejected. |
In situations where the SCL needs to be turned off, it is recommended that you add trusted servers/domains, as demonstrated in the sample below:
| Copy |
|---|
|
<system self="K2:DENALLIX\K2Service" enableListeners="true" allowAmbiguity="true"> <security spamSecurity="Off"> <!-- Default is InternalMail. --> <!-- A list of trusted domains that are checked against the RECEIVED-FROM header. --> <authorizedDomains> <add domain="*.denallix.com" /> </authorizedDomains> </security> </system> |
|
The SCL would need to be turned off for users responding to SmartActions-enabled notifications who do not have Exchange 2007 or Exchange 2010 accounts. |
authorizedDomains
This portion of K2 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 traversed trusted servers only. For this feature to be usable it requires that the header is completely valid as 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 Received headers.
This setting also supports the slight variation that Exchange adds. The following portions of the incoming e-mail are checked by, from and via parts are checked if they are present. If the element is empty or not present all domains are trusted, meaning this security check is skipped.
| CopyExample Code CS |
|---|
|
<authorizedDomains> |
Security Recommendations
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 will only action processes for which there has been an instantiation and the incoming e-mail 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 will have no impact on the corporate operations.
Two examples are shown below offering opposite extremes of security. The first is the most secure and the second is the least secure. Most secure configuration, using the fictitious Denallix domain as an example.
| CopyHigh Level SPAM Security Example CS |
|---|
| <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.
| CopyLow Level SPAM Security Example CS |
|---|
|
<security spamSecurity="Off" /> |
Ambiguity Configuration
The K2 environment can be configured to allow for multiple Labels to use the same provider. Each label would have an e-mail address associated with it. This means that multiple e-mail addresses could be found for the same user with each address being associated with a single label and unique to that label.
The following logic would apply:
- Get all the users under all the labels which have the incoming email address
- Sort the returned list of users according to their label alphabetically
- Place the default label first in the list
- Attempt to action the worklist item using the users in the list; in order
The outcome is that the end user would receive an e-mail notification for each of their email addresses that are found by the K2 Server. Each e-mail notification is however an independent notification with a unique serial number. If for example the end user actions an e-mail for the default label that item has been actioned and no further actions will be processed for the default label.
Shown below is the ambiguity configuration setting which is set be default to true. When true, the above functionality is operational. To disable, set the flag to false.
| CopySample Configuration Code CS |
|---|
|
<system allowAmbiguity="true" self="K2:POINTDISTRO\smartactions" enableListeners="true" > |
| Ambiguity Tags | |
|---|---|
| <ambiguity> | When true enables support for ambiguous environments where 2 Labels e.g. K2 and a Claims based environments would use the same provider. |
