SMTP Email Provider

The most common way to send out email messages is through the SMTP protocol.

Configuration#

The following configuration settings are available for the SMTP Email Provider:

ConfigurationMandatoryDescription
smtp-hostYesThe SMTP server name.
smtp-portYesThe port of the SMTP server. Defaults to 587.
enable-tlsYesWhether to use a TLS-protected connection to communicate with the server. Defaults to false.
default-senderYesAn 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>".
usernameNoA username to use to authenticate with the SMTP server.
passwordNoA password to use to authenticate with the SMTP server.

These settings must be used to configure SMTP email provider in the facilities section.

Configuring an SMTP Email Provider facility in the Curity Admin UI
Configuring an SMTP Email Provider facility in the Curity Admin UI. (Admin UI version: 10.6)

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 constraints 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 noreply@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.

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.

Embedded Content#

The SMTP email provider supports adding embedded/inline content to email messages. When the email data to be sent contains embedded content, the HTML version of the email message is a multipart message with additional parts for the embedded contents. Each part has a Content-ID which can be used to reference it from the main HTML body part using Content-ID URLs.

For more information on how to develop an SMTP Email message content plugin see the developer guide .

Was this helpful?