Email Providers¶

The task of sending email messages is used in different places, like when registering a new account, or using the Email authenticator. Email is normally sent through an SMTP server, that takes responsibility of delivering the email at the recipient’s mailbox. It is however also possible to use alternative email delivery services when using the Curity Identity Server.

An email provider is a pluggable component in Curity. By default, an SMTP-based email provider plugin is included with the server. An email provider is configured as a server facility, and therefore an email provider can be easily shared among multiple parts of the server configuration. Each configured service is able to configure its own email provider from the server’s facilities, allowing for easy default configuration of sending out emails in a standard way.

This section will describe how to configure the included SMTP email provider. Alternatively, it is possible to implement your own pluggable email provider through the Email Provider extension point, which is described in more detail in the developer’s guide.

SMTP Email Provider¶

The most common way to send out email messages, is through the SMTP protocol. To do this, the following configuration settings are available:

SMTP server name
The port of the SMTP server; defaults to 587
Whether to use a TLS-protected connection to communicate with the server
An email-address (RFC 822) that is used as the sender of each outgoing email message, accepting two formats: "user@host.domain" or "User Name <user@host.domain>"
Optionally, a username and password to use to authenticate with the SMTP server.

These settings must be used to configure Smtp in the facilities section.

Fig. 26 Configuring an Email facility in the Admin UI of Curity

DomainKeys Identified Mail¶

It is possible to sign messages sent via SMTP using DomainKeys Identified Mail (DKIM) Signatures. This helps the receiver know that the mail originated from a trustworthy source. The technique is defined in RFC 6376, and is well documented from various sources. The particulars of the implementation provided in the Curity Identity Server is described here. Specifically, the following constrains are important to be aware of:

Only RSA keys that are at least 1024 bits can be used to sign an email message.
Canonicalization is always performed using relaxed/relaxed. In other words, the body and headers are normalized using those methods, and this cannot be configured.
rsa-sha256 will always be used as the signing and hashing algorithm. This is not configurable.
The default-sender must include an at symbol (@).
The public key query method cannot be configured, so the default of dns/txt will be assumed by the email receiver.
The agent (or AUID) is always the same as the default-sender and is not configurable.
The signature timestamp and expiration cannot be specified.
The body signature length is never used.
Only the following headers will be signed (when applicable):

Cc
Content-Description
Content-Type

Date
From
Message-Id

MIME-Version
Sender

Subject
To

The SDID or domain that is used in the DKIM-Signature will be the one specified after the at symbol (@) of the default-sender.
The selector that is used in the DKIM-Signature must be in the same domain.

On the last two points, an example can help clarify the behavior. Suppose the default-sender was configured to be noreplay@example.com and the selector was configured to be brisbane, then the DKIM-Signature would include the tags d=example.com, s=brisbane, and i=noreply@example.com. Because the query method for the public key will always be assumed by the receiver to be text, for this example, the DNS TXT record brisbane._domainkey.example.com should be created that contains the public key.

Warning

If the DKIM signature is said to be invalid by the validator, check that the From email header that it received is the same as the value of the default-sender. If they are different, the signature will certainly be invalid.

Configure Email Provider for a Service¶

There is a zone wide setting to indicate which email provider should be used by default for the given zone. This setting is configured on the System’s Zones page.

Fig. 27 Setting up the default email provider for a zone