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.
The most common way to send out email messages, is through the SMTP protocol. To do this, the following configuration settings are available:
"User Name <firstname.lastname@example.org>"
These settings must be used to configure Smtp in the facilities section.
Fig. 25 Configuring an Email facility in the Admin UI of Curity
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:
On the last two points, an example can help clarify the behavior. Suppose the default-sender was configured to be email@example.com and the selector was configured to be brisbane, then the DKIM-Signature would include the tags d=example.com, s=brisbane, and firstname.lastname@example.org. 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.
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.
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. 26 Setting up the default email provider for a zone