Email Notification Issues

Before diving into troubleshooting, here are some quick questions to answer which will guide where to start your troubleshooting:

1. Are you receiving any emails from the intranet?
   • No - review the settings for Railo/Lucee or ColdFusion
   • Yes - Continue to #2
2. What emails are you missing? (e.g. Form submission notifications aren't getting through?)
3. Have you changed your Email domain?
4. Is your Web Server whitelisted to send email?

Step One: Verify the mail connection

1. Log in to the web administrator console by typing 
   http://[intranet server name, domain name or ip]/railo-context/admin/web.cfm
   or
   http://[intranet server name, domain name or ip]/lucee/admin/web.cfm
2. Enter the web admin password then, hit submit
3. Click Mail on the left menu
4. Select the checkbox next to the defined mail server and hit Verify

If the connection doesn't verify, you'll need to work with your mail administrator to troubleshoot and resolve the connectivity issues (e.g. specifying a port that is different than the default 25 port, enabling TLS or SSL, entering a username/password if authentication is required, etc). 

Step Two: Check for unsent emails

In the same Railo/Lucee interface as above, look to see if there are unsent emails.  You can also see the error messages that go along with them.

1. Click Tasks on the left menu
2. Look at the most recent entries if there are any.
3. Click the pencil icon on the right of the entry.
4. Take a screenshot of the error and send it to us or look it up online.

Relay Access Denied: If you look in Lucee Tasks and see that there's a message saying "Relay Access Denied SMTP", try this Microsoft article.

Step Three: Debug log

If the undelivered emails aren't displaying in the Task list, it's possible the emails have been sent from Lucee and the issue may be on the mail server side. To confirm the email was sent by Railo/Lucee, we can adjust the mail log settings to report on this:

1. In the same Railo/Lucee interface, select Server at the top of the screen and enter in your Server admin password (You can reset the password if you don't have your Server admin password)
2. Navigate to Settings: Logging > click the pencil icon next to mail
3. Next to Level, change this to 'Debug' and scroll down to click 'Submit' at the bottom of this screen
4. Try initiating another test to send a mail notification now that the logging level has been changed
5. Check the mail.log file, as mentioned in Step Four below, to see what Railo/Lucee is reporting

Step Four: My connection verifies, what next?

For Railo:

To understand why emails aren't being sent, the mail.log file provides error messages detailing the issues. This can be viewed in a text editor (e.g. Notepad).

1. Locate the mail.log file located in one of the following directories on your web server:
       Railo - {web root}\WEB-INF\railo\logs\mail.log (e.g. C:\inetpub\wwwroot\Intranet\WEB-INF\railo\logs\mail.log)
2. Review recent failed email notification entries in the mail.log
   • Identify issue and work with your mail server administrator to address any issues
   • Move the file into the \Mail\Spool folder
3. If issue persists:
   • Send a copy of your mail.log file to Support
   • Include a copy of one of the recent mail files from your undelivr folder that aren't being sent out
   • Which application/area you're working within on the Intranet?
   • Current version of the Intranet?

For Lucee:

1. Locate the mail.log file located in one of the following directories on your web server:
       Lucee - {web root}\WEB-INF\lucee\logs\mail.log. (e.g. C:\inetpub\wwwroot\Intranet\WEB-INF\lucee\logs\mail.log)

2.  Review recent failed email notification entries in the mail.log
      Identify issue and work with your mail server administrator to address any issues

3. If issue persists:

• Resend emails through Lucee admin (http://[your  intranet server name, domain name or ip]/lucee/admin/web.cfm) > Tasks > Execute
• Send a copy of your mail.log file to Support
• Include a copy of one of the recent mail files from your undelivr folder that aren't being sent out
• Which application/area you're working within on the Intranet?
• Current version of the Intranet?

Step One: Verify the mail connection

1. Log in to the ColdFusion administrator console by typing http://[intranet server name, domain name or ip]/cfide/administrator/index.cfm
2. Click Mail on the left menu
3. Check the box for the Verify mail server connection
4. Submit your changes

If the connection doesn't verify, you'll need to work with your mail administrator to troubleshoot and resolve the connectivity issues (e.g. specifying a port that is different than the default 25 port, enabling TLS or SSL, entering a username/password if authentication is required, white list the web server to send emails, etc). 

Step Two: Check for unsent emails

Undelivered emails are stored on the web server.  You can also see the error messages that go along with them.

1. On your Web server, navigate to the \Mail\Undelivr folder
   • CF 10: C:\ColdFusion10\CFusion\Mail\Undelivr
   • CF 9: C:\ColdFusion9\Mail\Undelivr
   • CF 8: C:\ColdFusion8\Mail\Undelivr
2. Using a text editor (e.g. Notepad), open the most recent mail file
   • Is the mail server or port number correct?
3. Move the file into the \Mail\Spool folder
4. On the Intranet, navigate to your Admin > Setup/Settings screen and click Run beside Scheduled Tasks
5. Did the mail file return back to the \Mail\Undelivr folder on the web server?
   • No - Move all undelivered mail files into the spool folder and run the Scheduled Task process once more
   • Yes - Proceed to Step Three

Step Three: Check Mail Logs for errors

To understand why emails aren't being sent, the mail.log file provides error messages detailing the issues. This can be viewed in a text editor (e.g. Notepad).

1. Locate the mail.log file located in one of the following directories on your web server:
   • CF 10 C:\ColdFusion10\cfusion\logs
   • CF 9: C:\ColdFusion9\logs
   • CF 8: C:\ColdFusion8\logs
2. Review recent failed email notification entries in the mail.log
   • Identify issue and work with your mail server administrator to address any issues
   • Move the file into the \Mail\Spool folder
3. If issue persists:
   • Send a copy of your mail.log file to Support
   • Include a copy of one of the recent mail files from your undelivr folder that aren't being sent out
   • Which application/area are you working within on the Intranet?
   • Current version of the Intranet?

System Notifications

When a notification triggers from an event, it's considered as a system notification. Some examples of these are:

• Workflow notifications - User submits an item into a workflow process which triggers system notifications to be sent
• Subscription alerts - subscribed alerts
• Support Desk alerts - Alerts are sent when a Ticket is assigned/unassigned, or when additional updates are added

This address can be located under Admin on the Setup Tab: Format Options: Email Options.

Send As Submitting User

When a notification is initiated by a user, the email is sent from that user. There are some options within the Intranet that allow notifications to come from a specific user. You may encounter this in the following ways:

• Online Forms - Send as submitting user allows the notification stage of your workflow to come from the submitting user rather than the system email address
• Birthday/Anniversary greetings - The user is able to send a greeting email to their colleague
• Training Calendar - Email notifications are sent from a user rather than the system admin
• Comments - When a user comments on an item, the notification is sent from their email address
• Feedback - If enabled, the feedback link at the top of your intranet comes from the user submitting the feedback

Mail servers may require that you allow Send As Anyone permissions to be granted in order for certain notifications to be allowed. You may encounter issues where notifications aren't being sent when the email comes from a specific user rather than the system email.

If your Exchange Server is hosted locally, you can configure Send As Anyone permissions as needed. Refer to the Microsoft article on managing Send As permissions.

Sending to external domains

We've recently received a number of reports from customers who are unable to have emails sent outside of their domain from the webserver. In order to allow this ability, we recommend whitelisting the webserver hosting the intranet from your email hosting provider/server. 

Further information may be found in this Microsoft article regarding SMTP Auth.