Skip to main content

Documentation Index

Fetch the complete documentation index at: https://support.lilt.com/llms.txt

Use this file to discover all available pages before exploring further.

  1. Self-Managed Documentation /
  2. System Administration /
  3. System Configuration
Skip table of contents LILT’s SMTP email integration enables customers to set up email integrations for core workflows like user sign up, job creation, job assignment, and job state changes. The following email integrations are available:
  • Account creation email, that invites new users to log into LILT for the first time.
  • Password reset email, so users can safely and securely reset their password.
  • Job creation email, so users know when a job has been successfully submitted.
  • New project assignment email, so linguists and users can accept or reject the project assignment.
    • There are three distinct emails: translator assignment email, reviewer assignment email, and Instant + Review assignment email.
  • Project rejection email, so users can effectively manage projects.
  • Project completion email, so users can track and understand progress.
  • Revision report email, for linguists to learn from errors and quality feedback.

​
PII-Safe Email Mode

For organizations with strict data privacy requirements (such as healthcare or financial services), LILT supports a PII-safe email mode that anonymizes document titles in assignment notification emails. When enabled:
  • Document names and job names are not included in email notifications
  • Assignment emails direct users to log into the LILT platform to view project details
  • The installation/customer name is displayed instead of specific job information
  • Applies to translator, reviewer, and secondary reviewer assignment emails
This feature helps prevent accidental exposure of sensitive information (PHI/PII) that may be contained in document or job names when emails are delivered outside of a secure environment.

​
Configuration instructions

In order to configure LILT’s SMTP Notifications feature, the following configurations must be set in $install_dir/lilt/environments/lilt/values.yaml The comments next to each value describe the information needed for each setting.

​
Notes:

  • white-list-email-domains is an optional value. Leaving empty indicates any domain is allowed to be sent to.
  • The bottom option1 is purposefully set to the empty string in order to overwrite the existing value. 
notification:
  enabled: true
  onpremValues:
    env:
      HIDE_PII_IN_EMAILS: "" # set to "true" to enable PII-safe email mode (anonymizes document titles)
      LILT_INSTALLATION_NAME: "" # customer/installation name displayed in PII-safe emails (required if HIDE_PII_IN_EMAILS is "true")
    app:
      args:
        defaultsenderemail: "" # default sender email. Required for sending emails
        notificationdomain: "" # domain to be used for sending email links to redirect the user back to the app. Required for sending emails
        white-list-email-domains: "" # comma separated list of email domains to be whitelisted for sending emails
        smtp-host: "" # smtp host. Required for sending emails
        smtp-port: "" # smtp port. Required for sending emails
        smtp-user: "" # smtp user. Required for sending emails
        smtp-password: "" # smtp password. Required for sending emails
front:
  onpremValues:
    env:
      MAILER_PROVIDER: ""
      MAILER_ENABLED: ""
      SMTP_HOST: ""
      SMTP_PORT: ""
      SMTP_USER: ""
      SMTP_PASS: ""
      MAILER_ADDRESSES_NOREPLY: ""
      SMTP_WHITELIST_DOMAINS: ""
assignment:
  onpremValues:
    app:
      args:
        option1: ""

​
SMTP Transport Security Options

By default, the notification service performs an opportunistic STARTTLS upgrade on every connection. For most SMTP relays this is the right behavior, but some self-managed deployments run against internal mail relays that:
  • listen on plain port 25 and do not advertise STARTTLS, or
  • advertise STARTTLS but present a certificate that the default JVM trust store does not accept, or
  • require implicit TLS (SMTPS) on a non-standard port such as 465.
To support these scenarios, the notification service exposes five additional environment variables. All of them are optional — the defaults below reproduce the historical behavior, so existing deployments do not need to change anything.
These transport-security variables are available starting in LILT 6.0 and beyond. Earlier releases (including LILT 5.3.x) force opportunistic STARTTLS and have no equivalent configuration.
VariableDefaultPurpose
SMTP_STARTTLS_ENABLE"true"Opportunistic STARTTLS upgrade on the SMTP connection. Set to "false" to permit unencrypted SMTP (for example, port 25 with no encryption).
SMTP_STARTTLS_REQUIRED"false"Require STARTTLS — the send fails if the server does not advertise it.
SMTP_SSL_ENABLE"false"Use SMTPS (implicit TLS) instead of plain SMTP. Typically paired with port 465.
SMTP_SSL_TRUST""Hosts to trust when verifying SMTP TLS certificates. Use "*" to trust all hosts (useful with internal CAs or self-signed certs).
SMTP_AUTH"" (derived)Explicit override for SMTP AUTH. When unset, auth is enabled if and only if smtp-password is non-empty.
These variables are set under notification.onpremValues.env in the same values.yaml shown above. They apply only to the notification service — the front pod uses a separate transport (see the front.onpremValues.env block above).

​
Example: unencrypted SMTP on port 25

If your relay accepts plaintext SMTP on port 25 with no auth and you want the notification pod to behave the same way the front pod already does: 
notification:
  enabled: true
  onpremValues:
    env:
      SMTP_STARTTLS_ENABLE: "false"
    app:
      args:
        defaultsenderemail: "noreply@example.com"
        notificationdomain: "example.com"
        smtp-host: "smtp-relay.internal"
        smtp-port: "25"
        smtp-user: ""
        smtp-password: ""

​
Example: SMTPS (implicit TLS) on port 465

notification:
  enabled: true
  onpremValues:
    env:
      SMTP_STARTTLS_ENABLE: "false"
      SMTP_SSL_ENABLE: "true"
    app:
      args:
        smtp-host: "smtp.example.com"
        smtp-port: "465"
        smtp-user: "username"
        smtp-password: "password"

​
Example: STARTTLS against an internal CA

If your relay advertises STARTTLS but uses a certificate from an internal CA that the JVM does not trust, add the host to SMTP_SSL_TRUST: 
notification:
  enabled: true
  onpremValues:
    env:
      SMTP_SSL_TRUST: "smtp.internal.example.com"
    app:
      args:
        smtp-host: "smtp.internal.example.com"
        smtp-port: "587"
        smtp-user: "username"
        smtp-password: "password"
Use SMTP_SSL_TRUST: "*" to trust any host — convenient for testing, but skip cert validation only when you understand the risk. Below is an example configuration: 
notification:
  enabled: true
  onpremValues:
    env:
      HIDE_PII_IN_EMAILS: "true"
      LILT_INSTALLATION_NAME: "Example Corp"
    app:
      args:
        defaultsenderemail: "user@example.com"
        notificationdomain: "example.com"
        white-list-email-domains: "test.com"
        smtp-host: "smtp.example.com"
        smtp-port: "587"
        smtp-user: "username"
        smtp-password: "password"
front:
  onpremValues:
    env:
      MAILER_PROVIDER: "smtp"
      MAILER_ENABLED: "true"
      SMTP_HOST: "smtp.example.com"
      SMTP_PORT: "587"
      SMTP_USER: "username"
      SMTP_PASS: "password"
      MAILER_ADDRESSES_NOREPLY: "user@example.com"
      SMTP_WHITELIST_DOMAINS: "test.com"
assignment:
  onpremValues:
    app:
      args:
        option1: ""