Resolving Ignition 8.1.48 SMTP Profiles in Modules

Ignition 8.1.48 modules should submit email through the Gateway-managed SMTP profile instead of copying its hostname, port, TLS settings, username, or password into module code. The request path is: module code to GatewayContext, then EmailProfileManager, then the named EmailProfile, and finally sendEmail. This preserves the Gateway as the owner of SMTP configuration and credentials.

Where Should the SMTP Request Start?

Follow the packet. The module creates the message, but the managed email profile supplies the connection policy and sends it toward the SMTP server. Retrieving every underlying setting adds a second configuration path and makes the module responsible for secrets, TLS behavior, and future profile changes.

Direct access to the profile's underlying settings is possible through the same general subsystem, but it is the wrong dependency when the module's actual job is sending mail. Pass the message to the managed profile unless the module truly must display or migrate configuration. Never copy the profile password into logs, diagnostics, module configuration, or exception text.

Does the Gateway Version Expose the Required Manager?

The first decision is API compatibility. EmailProfileManager, in package com.inductiveautomation.ignition.gateway.mail, was introduced in Ignition 8.1.24. Ignition 8.1.48 is therefore above the introduction point and can use this interface.

Compile-time success alone is not the deciding test. The installed Gateway runtime must also satisfy the module's declared compatibility floor. Otherwise, class loading or linkage can fail before any SMTP request reaches the network.

Can the Module Resolve the Named Profile?

After obtaining the manager from GatewayContext, resolve the email profile by its configured name. Treat that name as a module setting rather than embedding it throughout the code. A missing result means the data path stopped inside the Gateway; changing ports, certificates, or firewall rules cannot repair a name-resolution failure.

1. Read the profile name from the module's configuration.
2. Obtain the Gateway email profile manager through GatewayContext.
3. Ask the manager for the profile with that name.
4. If no profile resolves, report the profile name and stop before constructing a network diagnosis.
5. If an EmailProfile resolves, hand the prepared message to sendEmail.

GatewayContext
  -> EmailProfileManager
  -> resolve profile by configured name
  -> EmailProfile
  -> sendEmail(message)

This object path is the stable integration boundary. It avoids making the module interpret whether a hostname, port, SSL option, STARTTLS option, username, and password form a valid combination.

Where Does the Request Stop After Profile Resolution?

Layer one first. Once profile lookup succeeds, locate the last successful hop before changing application settings. Inspect the Gateway host's network link and routing, then name resolution, TCP establishment, TLS negotiation when configured, SMTP authentication, and message acceptance—in that order.

No universal port or timing value can be inferred from the requested fields. Read the hostname, port, connection mode, and timeout behavior from the configured profile and the SMTP service documentation. A port number and a TLS checkbox are not independent guesses: they describe one endpoint contract.

How Should the Module Send Through the Managed Profile?

Keep the module boundary narrow: accept a profile name plus message data, resolve the managed object, and invoke its send operation. Do not accept a password merely to reproduce a Gateway profile internally.

1. Declare Ignition 8.1.24 as the minimum supported runtime if the module depends unconditionally on EmailProfileManager.
2. Expose the target profile name as module configuration.
3. Obtain EmailProfileManager from GatewayContext.
4. Resolve the named EmailProfile and fail locally with a clear profile-name diagnostic when it is absent.
5. Create the email message using the data required by the profile's sendEmail operation.
6. Call sendEmail and let the Gateway-managed profile apply its hostname, port, encryption, and authentication configuration.
7. Record operational success or failure without recording credentials or full sensitive message content.

If the business requirement is configuration inspection rather than message delivery, separate that feature from sending. Apply authorization, redact the password, and expose only fields required by the operator-facing function. Configuration extraction should not become the normal send path.

How Do You Verify the Resolving Branch?

Verification must distinguish profile resolution, endpoint reachability, server acceptance, and final delivery. A successful lookup proves only that the Gateway contains a profile with the requested name. A successful TCP connection proves only network reachability. SMTP acceptance still does not prove that a downstream mailbox retained or displayed the message.

1. Run the module on Ignition 8.1.48 and confirm that it obtains EmailProfileManager.
2. Test an intentionally invalid profile name and confirm that the module stops at lookup with a profile-specific diagnostic.
3. Restore the valid name and send a controlled message through EmailProfile.sendEmail.
4. Check Gateway diagnostics for name-resolution, connection, TLS, authentication, or SMTP rejection failures.
5. Confirm acceptance at the SMTP service, then verify the controlled message at its intended destination.

FAQ