{"id":"6a6b340d050281485e7e0f98","title":"2026 07 30 Issue 341","path":"how-to/committee/release-notes/2026-07-30-issue-341","contentMarkdown":"# 30-Jul-2026 — keep the Brevo SMTP key active so re-send routing stops bouncing [ref #341](https://github.com/nbarrett/ngx-ramblers/issues/341)\n\n## [build 805](https://github.com/nbarrett/ngx-ramblers/actions/runs/30537275334) — [commit 137ad2e](https://github.com/nbarrett/ngx-ramblers/commit/137ad2e35fdb41fbd5be0d9992dd16e0970aeb62)\n\n_____\n\nBrevo marks an SMTP key inactive after three months without a send. That key is a\nseparate credential from the REST API key, used only by Cloudflare Email Routing in\nBrevo re-send mode. Low-traffic role addresses can go three months without a single\nmessage, so the key expires purely from disuse while the routing rule is still enabled.\n\nWhen that happens the failure is not graceful: the relay fails, Cloudflare rejects the\nmessage, and anyone emailing that role address gets a bounce. Nothing in the admin UI\nwarns beforehand.\n\nAdds a monthly keepalive task that sends one probe through the same relay the inbound\nrouting uses, which resets the inactivity clock and doubles as an end-to-end check. It\nappears in Scheduled Tasks with run history, an enable toggle, an editable schedule and\na manual trigger, so a failure shows up there rather than as a bounce to a member. The\nprobe recipient is configurable in Mail Settings and falls back to the SMTP login, and\nthe task skips itself on sites that do not use Brevo re-send.\n\nScheduling it monthly exposed a defect in overdue detection, fixed here too. The\nwatchdog treated any day-of-month schedule as a flat 28 days, which for a monthly task\npointed the previous expected run a few days after the run that actually happened, so it\nwould raise a missed-run alert and re-run the task every month. Overdue detection now\nworks out the true previous occurrence from the schedule itself. Checked against all\nseven existing schedules: only the monthly one moves, to the correct date, and genuine\nmissed-run recovery still works.","contentHtml":"<h1>30-Jul-2026 — keep the Brevo SMTP key active so re-send routing stops bouncing <a href=\"https://github.com/nbarrett/ngx-ramblers/issues/341\">ref #341</a></h1>\n<h2><a href=\"https://github.com/nbarrett/ngx-ramblers/actions/runs/30537275334\">build 805</a> — <a href=\"https://github.com/nbarrett/ngx-ramblers/commit/137ad2e35fdb41fbd5be0d9992dd16e0970aeb62\">commit 137ad2e</a></h2>\n<hr>\n<p>Brevo marks an SMTP key inactive after three months without a send. That key is a\nseparate credential from the REST API key, used only by Cloudflare Email Routing in\nBrevo re-send mode. Low-traffic role addresses can go three months without a single\nmessage, so the key expires purely from disuse while the routing rule is still enabled.</p>\n<p>When that happens the failure is not graceful: the relay fails, Cloudflare rejects the\nmessage, and anyone emailing that role address gets a bounce. Nothing in the admin UI\nwarns beforehand.</p>\n<p>Adds a monthly keepalive task that sends one probe through the same relay the inbound\nrouting uses, which resets the inactivity clock and doubles as an end-to-end check. It\nappears in Scheduled Tasks with run history, an enable toggle, an editable schedule and\na manual trigger, so a failure shows up there rather than as a bounce to a member. The\nprobe recipient is configurable in Mail Settings and falls back to the SMTP login, and\nthe task skips itself on sites that do not use Brevo re-send.</p>\n<p>Scheduling it monthly exposed a defect in overdue detection, fixed here too. The\nwatchdog treated any day-of-month schedule as a flat 28 days, which for a monthly task\npointed the previous expected run a few days after the run that actually happened, so it\nwould raise a missed-run alert and re-run the task every month. Overdue detection now\nworks out the true previous occurrence from the schedule itself. Checked against all\nseven existing schedules: only the monthly one moves, to the correct date, and genuine\nmissed-run recovery still works.</p>\n"}