Securing email

Niagara supports secure outgoing and incoming email using TLS (Transport Layer Security).

Prerequisites: The EmailService is in your Services container with both IncomingAccount and OutgoingAccount components. If not, add the EmailService component from the email palette before you begin. You may have multiple incoming and outgoing accounts, which allow you to set up connections to servers that support secure communication and others that may not.

Follow this procedure for both your incoming and outgoing accounts.

Perform the following steps:

In the station's Nav tree, right-click the IncomingAccount or OutgoingAccount node under the EmailService container and click Views > Property Sheet.
The account Property Sheet opens.

The system provides two secure communication options:
- The default, Use Ssl, encrypts the connection before it is ever opened. To do the encryption, it automatically uses either SSL v3 or TLS (depending on email server requirements). This provides the most secure data transmission since the connection is encrypted from the start.
- Use Start Tls makes it possible to connect to an unprotected email server. The handshake occurs without encryption, then switches to encrypt the message itself.
Use Ssl and Use Start Tls are mutually exclusive. Both may be false.

To provide secure email, set one property to true, and the other false.

The example shows the configuration when Transport is set to Smtp.

Incoming and outgoing messages use different ports for secure communication as follows:

Email ports based on transport type

	Outgoing (SMTP)	Incoming (IMAP)	Incoming (POP3)
Not encrypted	25	143	110
Use Start Tls	587	143	110
Use Ssl	465	993	995

Not all servers follow these rules. You may need to check with your ISP (Internet Service Provider).

NOTE: Do not enable or disable the Use Ssl or Use Start Tls properties without configuring the Port.

Change the Port to the appropriate port number (defaults are: 25 for outgoing and 110 for incoming email).
The system also provides server identity verification. For most email servers, the root certificate is already in the System Trust Store.
If no root CA certificate for the email server is in the station's System Trust Store (third-party signed certificate) or in the User Trust Store (your own certificate if you provide your own secure email server), either:
- Import your own or a third-party signed root CA certificate into the station’s User Trust Store.
- Or, if you do not have a signed certificate yet, accept the system-generated, self-signed certificate when challenged. This creates an exemption in the Allowed Hosts list. Later, import the root CA certificate and delete this temporary exemption.

Securing email

Email ports based on transport type

Related Links