feat(mail): reissue Sweego credentials and move sending to mail.gitborg.se #272

Sammanfogat

supernaut sammanfogade 1 incheckning från sweego-credentials in i main

2026-07-31 01:00:08 +00:00

supernaut kommenterad

2026-07-31 00:42:17 +00:00

Ägare

Reissues the Sweego credentials and moves the outbound sending domain from email.gitborg.se to
mail.gitborg.se.

Changes

File	Change
`group_vars/all/vars.yml`	`forgejo_mailer_from` → `bitborg <no-reply@mail.gitborg.se>`
`group_vars/all/vault.yml`	Reissued mailer credentials (re-encrypted)
`group_vars/vault.example.yml`	Comments updated to the new domain
`roles/monitoring/defaults/main.yml`	`alert_email_from` → `alerts@mail.gitborg.se`
`roles/monitoring-agent/defaults/main.yml`	`monitoring_probe_mail_from` → `alerts@mail.gitborg.se`
`roles/web/templates/bitborg-web.container.j2`	Comment updated to the new domain

Alertmanager and the blackbox probe reuse the same relay credentials
(alert_smtp_* → vault_forgejo_mailer_*), so they are covered by the same apply. Sweego verifies
the domain, not the local part, so alerts@ needs no separate setup.

DNS state (verified live)

Record	Result
`sweego1._domainkey.mail.gitborg.se`	✅ CNAME → `…-dkim.sweego.co`, valid `v=DKIM1` key
`_dmarc.mail.gitborg.se`	✅ `v=DMARC1; p=none;`
`TXT mail.gitborg.se` (SPF)	❌ none
`gitborg.se` apex SPF	`include:spf.messagingengine.com ?all` — does not authorise Sweego

The absent SPF record is most likely fine: SPF authenticates the envelope Return-Path, which Sweego
owns, and DMARC passes on DKIM alignment alone (d=mail.gitborg.se aligns with the From under
relaxed alignment). Worth confirming the Sweego dashboard shows the domain fully verified and is not
asking for a return-path record — bounce, bounces, return, rp, tracking, link, click
and t were probed and none exist.

Companion change — required, not optional

The portal's From address is hardcoded in bitborg-web and not env-configurable, so this PR cannot
move it. Without gitborg/gitborg-web#114, portal mail keeps sending as no-reply@email.gitborg.se,
which now has no DNS records at all — Sweego will likely reject it as an unverified sending domain,
and anything delivered would fail DKIM alignment. The affected path is the sign-up credential-reset
email, so sign-up completes and the user never gets the link.

Follow-up for the duplication itself: gitborg/gitborg-web#113.

Apply notes

Until this is applied, production Forgejo and Alertmanager still hold the previous credentials.
If those were revoked when the new ones were issued, outbound mail from Forgejo is already failing —
Loki showed no SMTP errors in the last 24 h, but also no send attempts, so that is not evidence of
health either way.

Verify after applying:

Forgejo test mail from the admin panel, and an Alertmanager test notification.
On a received message, confirm dkim=pass with d=mail.gitborg.se.
A sign-up end-to-end, once gitborg/gitborg-web#114 has deployed.

Separately: DMARC is p=none, so none of this is policy-enforced. Once both senders are on the new
domain and confirmed passing, tightening to p=quarantine is cheap hardening — out of scope here.

Reissues the Sweego credentials and moves the outbound sending domain from `email.gitborg.se` to `mail.gitborg.se`. ## Changes | File | Change | | --- | --- | | `group_vars/all/vars.yml` | `forgejo_mailer_from` → `bitborg <no-reply@mail.gitborg.se>` | | `group_vars/all/vault.yml` | Reissued mailer credentials (re-encrypted) | | `group_vars/vault.example.yml` | Comments updated to the new domain | | `roles/monitoring/defaults/main.yml` | `alert_email_from` → `alerts@mail.gitborg.se` | | `roles/monitoring-agent/defaults/main.yml` | `monitoring_probe_mail_from` → `alerts@mail.gitborg.se` | | `roles/web/templates/bitborg-web.container.j2` | Comment updated to the new domain | Alertmanager and the blackbox probe reuse the same relay credentials (`alert_smtp_*` → `vault_forgejo_mailer_*`), so they are covered by the same apply. Sweego verifies the *domain*, not the local part, so `alerts@` needs no separate setup. ## DNS state (verified live) | Record | Result | | --- | --- | | `sweego1._domainkey.mail.gitborg.se` | ✅ CNAME → `…-dkim.sweego.co`, valid `v=DKIM1` key | | `_dmarc.mail.gitborg.se` | ✅ `v=DMARC1; p=none;` | | `TXT mail.gitborg.se` (SPF) | ❌ none | | `gitborg.se` apex SPF | `include:spf.messagingengine.com ?all` — does not authorise Sweego | The absent SPF record is most likely fine: SPF authenticates the envelope Return-Path, which Sweego owns, and DMARC passes on DKIM alignment alone (`d=mail.gitborg.se` aligns with the From under relaxed alignment). Worth confirming the Sweego dashboard shows the domain fully verified and is not asking for a return-path record — `bounce`, `bounces`, `return`, `rp`, `tracking`, `link`, `click` and `t` were probed and none exist. ## Companion change — required, not optional The portal's From address is **hardcoded in bitborg-web and not env-configurable**, so this PR cannot move it. Without gitborg/gitborg-web#114, portal mail keeps sending as `no-reply@email.gitborg.se`, which now has no DNS records at all — Sweego will likely reject it as an unverified sending domain, and anything delivered would fail DKIM alignment. The affected path is the sign-up credential-reset email, so sign-up completes and the user never gets the link. Follow-up for the duplication itself: gitborg/gitborg-web#113. ## Apply notes Until this is applied, production Forgejo and Alertmanager still hold the **previous** credentials. If those were revoked when the new ones were issued, outbound mail from Forgejo is already failing — Loki showed no SMTP errors in the last 24 h, but also no send attempts, so that is not evidence of health either way. Verify after applying: 1. Forgejo test mail from the admin panel, and an Alertmanager test notification. 2. On a received message, confirm `dkim=pass` with `d=mail.gitborg.se`. 3. A sign-up end-to-end, once gitborg/gitborg-web#114 has deployed. Separately: DMARC is `p=none`, so none of this is policy-enforced. Once both senders are on the new domain and confirmed passing, tightening to `p=quarantine` is cheap hardening — out of scope here.

supernaut lade till 1 incheckning

2026-07-31 00:42:18 +00:00

feat: set new email credentials

ci / ci (pull_request) Successful in 1m27s

Detaljer

ad85f03721