You may want to limit outbound email during service design testing or in nonproduction environments.
By limiting outbound email capabilities, you can limit or prevent the sending of email to actual performers or customers on whose behalf services are ordered.
Changing all email templates to have “fake addresses” in a development environment is not really an option. Firstly, it would be very time consuming. More important, much of the testing is invalidated when the template addresses are changed back—you would still need to ascertain that the correct people are receiving the appropriate emails.
If templates use only namespace variables and users in the nonproduction environment are refreshed via directory integration, you could change the LDAP mapping to give everyone the same email address or a similar fake address, for example:
by using a mapping similar to:
However, this approach also does not allow you to adequately test the accuracy of email delivery.
A more robust solution is to use a dedicated SMTP (email) server for the development instance and any other instances where emails should not be distributed outside the box. You can set up an SMTP server that routes ALL emails (whether fake or correct) to a standard mailbox (for example, firstname.lastname@example.org) for the development and test servers. This way, you do not have to change Service Catalog configuration in any way, and emails could be tested very easily. The project team just needs to be able to open that test mailbox.
This requires users to configure a separate test SMTP server that overrides the recipients to always forward to the test email box. Production would need to point to the production SMTP server, of course.
If you use any of these techniques, add the To/Cc addressees in the HTML body of the email templates surrounded by <!-- Comment --> tags so that testers may validate the namespace expression and other logic for these fields.
Controlling Email Generation
Service Catalog controls the outgoing email envelope and defaults to sending a single message to multiple recipients. The multiple-recipient messages are sent to the same SMTP server.
The alternative is to send single recipient emails as it has a minimal negative effect on CPU and network bandwidth usage. This is enabled via a setting in the newscale.properties file:
Use this setting only to avoid SMTP server problems whereby the entire message is rejected if one recipient is invalid.
SMTP Connections are tried 10 times (by default) and are configured by the Email.ServerDownCount property. The connection retries to the SMTP host are paused for the configured time (in msec) specified in the Email.RescheduleOffset property.
In addition, issues such as configured mailbox exceeding the set limit, email bounces, or other delivery problems are retried based on the default setting of the Email.RetryCount property (currently, the default is 4).