Summary
Dev and stage have no outbound mail interception. Drupal on those environments can send real email to real recipients whose addresses come from configuration rather than from user accounts - webform handler notifications being the most likely path.
The Vortex template ships drupal/reroute_email in its default module set to cover exactly this; this project does not have it or any equivalent.
Details
Current mail guards, and what each does not cover:
-
$settings['suspend_mail_send'] = TRUE in web/sites/default/includes/modules/settings.do_base.php. This is the only Drupal-level guard, and it is scoped to ENVIRONMENT_CI only:
if ($settings['environment'] === ENVIRONMENT_CI) {
// Disable mail send out.
$settings['suspend_mail_send'] = TRUE;
}
Dev and stage fall straight through this condition.
-
Database sanitisation rewrites user addresses via VORTEX_PROVISION_SANITIZE_DB_EMAIL=user_%uid@drevops.com. This protects mail addressed to user accounts, but it does not touch recipients stored in configuration - webform handler "send to" addresses, contact form recipients, or the site mail address.
Exposure: the project has drupal/webform: ^6.3@beta. A webform handler configured to notify a fixed address will send from dev or stage to that real address on any form submission, including submissions generated during testing.
What Vortex expects: drupal/reroute_email: ^2.3@RC, listed in the installer's default modules answer. It intercepts all outbound mail and redirects it to a single configured address regardless of the original recipient.
Why it stayed invisible until now: the Vortex installer discovers its answers from the codebase, and for modules that discovery is effectively "is the package in composer.json". Because reroute_email was absent, the installer answered "no" to it and stripped it from the rendered composer.json - so it never appeared as a diff during any previous update.
Proposed fix
- Add
drupal/reroute_email and enable it on dev and stage.
- Configure the reroute address per environment via
settings.reroute_email.php under web/sites/default/includes/modules/, following the existing per-module settings pattern.
- Leave production untouched.
- Confirm the CI behaviour still holds -
suspend_mail_send on CI and rerouting on dev and stage are complementary, not conflicting.
Alternatively, if mail is already blocked for these environments at the platform or SMTP level outside Drupal, document that and close this as an accepted divergence.
Acceptance criteria
Summary
Dev and stage have no outbound mail interception. Drupal on those environments can send real email to real recipients whose addresses come from configuration rather than from user accounts - webform handler notifications being the most likely path.
The Vortex template ships
drupal/reroute_emailin its default module set to cover exactly this; this project does not have it or any equivalent.Details
Current mail guards, and what each does not cover:
$settings['suspend_mail_send'] = TRUEinweb/sites/default/includes/modules/settings.do_base.php. This is the only Drupal-level guard, and it is scoped toENVIRONMENT_CIonly:Dev and stage fall straight through this condition.
Database sanitisation rewrites user addresses via
VORTEX_PROVISION_SANITIZE_DB_EMAIL=user_%uid@drevops.com. This protects mail addressed to user accounts, but it does not touch recipients stored in configuration - webform handler "send to" addresses, contact form recipients, or the site mail address.Exposure: the project has
drupal/webform: ^6.3@beta. A webform handler configured to notify a fixed address will send from dev or stage to that real address on any form submission, including submissions generated during testing.What Vortex expects:
drupal/reroute_email: ^2.3@RC, listed in the installer's defaultmodulesanswer. It intercepts all outbound mail and redirects it to a single configured address regardless of the original recipient.Why it stayed invisible until now: the Vortex installer discovers its answers from the codebase, and for modules that discovery is effectively "is the package in
composer.json". Becausereroute_emailwas absent, the installer answered "no" to it and stripped it from the renderedcomposer.json- so it never appeared as a diff during any previous update.Proposed fix
drupal/reroute_emailand enable it on dev and stage.settings.reroute_email.phpunderweb/sites/default/includes/modules/, following the existing per-module settings pattern.suspend_mail_sendon CI and rerouting on dev and stage are complementary, not conflicting.Alternatively, if mail is already blocked for these environments at the platform or SMTP level outside Drupal, document that and close this as an accepted divergence.
Acceptance criteria