As a user, I want to a simple way to send email from dotCMS.
This is probably an "Epic" change that will require substantial input from others. I will try to provide a description of the common issues we see in support.
The dotCMS “outbound email” story has become difficult to understand and support. This complexity is magnified considerably by modern SMTP security constraints, such as SPF and DKIM, which are themselves confusing to many developers, and which content/web developers may have no control over. These SMTP security constraints did not exist when dotCMS’ outbound email features were created.
Most, if not all, of these email issues involve being unable to send mail due restrictions by the SMTP relay servers on the email “From address.” The "From address" that dotCMS sets on an outbound email depends on which dotCMS feature or tool generated that email. On that note, remember that there are two "From" addresses on SMTP messages
the "envelope from" that is transmitted in the SMTP handshake, and
the From: <me@foo.com> line in the email message body
and there are SMTP security constraints on how these may differ.
In some cases, like Workflow Notifications, a dotCMS content editor may not have control over
the "From" address that dotCMS is using on an outbound email, nor
the "From" addresses that the configured SMTP relay server will allow
therefore dotCMS simply cannot send these notification emails.
Current Email Sources and their "From" address
Since managing the “From” address is essential, dotCMS users must learn how different dotCMS features determine the “From” address for a given email. Users must also understand the constraints of the SMTP relay server in use.
A list of dotCMS email sources and their “From” addresses, likely incomplete:
Backend password reset emails via /dotAdmin/#/public/forgotPassword:
From address: Basic Config -> Email Address
Workflow Subactions “Notify Assignee/Notify Users”
From address: I think this is a dotCMS user’s email address - not sure which user, maybe the
workflow creator?
If there are dotCMS users with email addresses in multiple domains,
then it may be impossible to send these notification emails.
Workflow Subactions: “Send an Email”
From address: any address can be specified in the Workflow's “From Email” field
Form Submission Notifications
From address: I don’t know
Some SMTP servers are configured to not allow the “from” email address (in the $mail viewtool call) to be different than the logged in user (in the dotCMS mail configuration), to prevent spoofing of emails. Therefore if the “from” email in the $mail call is different from the SMTP user account specified in the dotCMS mail configuration, the SMTP server must be configured to allow sending from a different email address than the login email.
Other sources of email??
6a. I don’t know what uses these addresses - see fake emails for anonymous and system users
It is not possible for any SMTP server to send mail From either of these addresses.
final static String SYSTEM_USER_EMAIL = "system@dotcms.systemuser";
final static String CMS_ANON_USER_EMAIL = "anonymous@dotcms.anonymoususer";
user = createUser(SYSTEM_USER_ID, SYSTEM_USER_EMAIL);
user = createUser(CMS_ANON_USER_ID, CMS_ANON_USER_EMAIL);
Common SMTP Relay Server Constraints
In many cases, the configured SMTP relay server will accept email "From" only a single email address. In such a case we recommend using something like
no-reply@example.com or notifications@example.com or notifications@noreply.example.com
Is some cases, the SMTP server may accept mail from any address in a domain *@example.com. This can improve the delivery for, say, Workflow "Notify" sub-action emails if all the dotCMS user accounts use an email address in a single domain. It is not possible to send a "Notify" sub-action email from domains like gmail.com.
Please see the Google Doc in External Links for more details
Acceptance Criteria
Exact criteria unknown. This is a big change touching many different parts of the application.
Currently, we can set only a single, server-wide, configuration for the SMTP relay server https://www.dotcms.com/docs/latest/mail-configuration
We could add an additional property like DOT_MAIL_FROM_ADDRESS which would be used as the default From address on all outbound email. This may be sufficient for most customers.
We probably want to provide the ability to set a custom From address on most outbound email messages. For example, our current Workflow "Notify Users" and "Notify Assignee" sub-actions do not allow users to specify the From address, so sometimes these messages cannot be delivered.
Send email asynchronously!
Beyond that, it may be useful to be able to store the settings for multiple SMTP servers in some way, such as for multi-tenant setups.
Proposed Objective
Core Features
Proposed Priority
Priority 2 - Important
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
Ticket related to a customer: sending emails async would resolve most of their issues and others when sending emails as part of workflows in dotCMS. If this is a piece of the above request we can easily accomplish, I highly suggest we look into it
ian-b-cooper
commented
7 months ago
Related Issue
Provide the ability to set custom headers on outgoing email messages #24278
User Story
As a user, I want to a simple way to send email from dotCMS.
This is probably an "Epic" change that will require substantial input from others. I will try to provide a description of the common issues we see in support.
The dotCMS “outbound email” story has become difficult to understand and support. This complexity is magnified considerably by modern SMTP security constraints, such as SPF and DKIM, which are themselves confusing to many developers, and which content/web developers may have no control over. These SMTP security constraints did not exist when dotCMS’ outbound email features were created.
Most, if not all, of these email issues involve being unable to send mail due restrictions by the SMTP relay servers on the email “From address.” The "From address" that dotCMS sets on an outbound email depends on which dotCMS feature or tool generated that email. On that note, remember that there are two "From" addresses on SMTP messages
From: <me@foo.com>line in the email message bodyand there are SMTP security constraints on how these may differ.
In some cases, like Workflow Notifications, a dotCMS content editor may not have control over
therefore dotCMS simply cannot send these notification emails.
Current Email Sources and their "From" address
Since managing the “From” address is essential, dotCMS users must learn how different dotCMS features determine the “From” address for a given email. Users must also understand the constraints of the SMTP relay server in use.
A list of dotCMS email sources and their “From” addresses, likely incomplete:
/dotAdmin/#/public/forgotPassword:From address:Basic Config -> Email AddressFrom address:I think this is a dotCMS user’s email address - not sure which user, maybe the workflow creator? If there are dotCMS users with email addresses in multiple domains, then it may be impossible to send these notification emails.From address:any address can be specified in the Workflow's “From Email” fieldFrom address:I don’t knowCommon SMTP Relay Server Constraints
In many cases, the configured SMTP relay server will accept email "From" only a single email address. In such a case we recommend using something like
no-reply@example.comornotifications@example.comornotifications@noreply.example.comIs some cases, the SMTP server may accept mail from any address in a domain
*@example.com. This can improve the delivery for, say, Workflow "Notify" sub-action emails if all the dotCMS user accounts use an email address in a single domain. It is not possible to send a "Notify" sub-action email from domains likegmail.com.Please see the Google Doc in External Links for more details
Acceptance Criteria
Exact criteria unknown. This is a big change touching many different parts of the application.
DOT_MAIL_FROM_ADDRESSwhich would be used as the default From address on all outbound email. This may be sufficient for most customers.Beyond that, it may be useful to be able to store the settings for multiple SMTP servers in some way, such as for multi-tenant setups.
Proposed Objective
Core Features
Proposed Priority
Priority 2 - Important
External Links... Slack Conversations, Support Tickets, Figma Designs, etc.
More details here:
https://docs.google.com/document/d/1Y2qCJ5QQOu0uqW9--FDSSBYCZTuqCklZA834h5F_EWQ/edit
Assumptions & Initiation Needs
No response
Quality Assurance Notes & Workarounds
No response
Sub-Tasks & Estimates
No response