Email Connector: redirect all outgoing e-mail to a test e-mail address - Mendix Forum

Email Connector: redirect all outgoing e-mail to a test e-mail address

9

During developing, testing or debugging, sometimes actual e-mail addresses are present in the test or acceptance database, for example after a temporary copy of the data from the production environment.


We really want to avoid sending e-mails to actual persons in the outside world.


So please add a constant for a test e-mail address that, when filled, makes sure that all outgoing e-mail (including CC and BCC) are not sent to the addressed person(s), but to this test e-mail address.

asked
2 answers

Thanks for your suggestion, we will look into it.


There seems to be a misunderstanding: my suggestion was not to add logic that's different on each environment, but to add support for a constant that optionally holds an e-mail address. On Test and Acceptance this could be filled so all e-mail would be sent to that address. On production this constant should be left empty. In this way no environment-specific logic would be needed.

Created

Hey Axl,

we use https://mailpit.axllent.org


If the goal is just to avoid sending emails from non-production environments, I’d actually question whether adding a constant to indicate “environment” inside the email module is the best solution.


In test scenarios, tools like Mailpit tend to work better than trying to make production SMTP behaviour environment-aware.


Instead of teaching your mailer when not to send, you swap the SMTP backend itself.


Why this is usually preferable:


  • No risk of real emails going out
  • With Mailpit, messages are captured locally and never leave your system. You don’t have to rely on flags or constants being set correctly.
  • Cleaner separation of concerns
  • The mail module shouldn’t really need to know whether it’s running in dev/test/prod. It just sends via whatever SMTP server it’s configured with. Environment handling becomes infrastructure/config, not application logic.
  • Better debugging
  • Mailpit gives you a web UI to inspect HTML, headers, attachments, etc. That’s much easier than checking real inboxes or sprinkling extra logging in your code.
  • More reliable automated tests
  • Tests can query Mailpit’s API and assert that an email was sent, check subjects/links, etc. Production SMTP servers make this hard or flaky.
  • Faster and cheaper
  • No rate limits, no external latency, no credentials needed for local testing.



So rather than introducing something like:

if (ENVIRONMENT !== 'production') {

// don't send email

}

a more robust approach is usually:

dev/test -> smtp://localhost:1025 (Mailpit)

staging -> sandbox SMTP provider

prod -> real SMTP server

Your mail module stays simple, and environment differences live in configuration where they belong.


Just my experience: once you move to a local SMTP catcher, the need for environment constants in the mail code mostly disappears.




Created