docs(mail): record that the SMTP path is verified for both domains #386

Sammanfogat
supernaut sammanfogade 1 incheckning från docs/smtp-path-verified in i main 2026-08-05 20:02:38 +00:00
Ägare

Closes a real gap in the §5 procedure: step 0 as written only exercises the HTTP API, which is the portal's path.

Forgejo, Alertmanager and the monitoring cross-probe all send over SMTP — a different credential with its own authorisation list. Step 3 repoints forgejo_mailer_from, alert_email_from and monitoring_probe_mail_from at the new domain, so SMTP must authorise it too, and an API pass says nothing about that.

Verified after the credential rotation (#385)

From both hosts, since Alertmanager sends from the monitoring VM with its own egress. Mirrors the cross-probe's own curl invocation, so a pass here means that probe will work.

sender services host monitoring host
alerts@mail.gitborg.se rc=0 rc=0
no-reply@email.bitborg.se rc=0 rc=0

Step 3's SMTP prerequisite therefore holds.

With controls, because four rc=0 results are not evidence

control result proves
unauthorised sender domain + correct password rc=8 "Weird server reply" the relay does enforce the sender
known-good sender + wrong password rc=67 "Login denied" AUTH is exercised

Without these, the email.bitborg.se pass would be equally consistent with a relay that accepts anything — which would have made it worthless as a step 3 prerequisite. Same discipline that caught /channels answering 200 while completely unauthenticated in #385.

Docs only; no behaviour change. Both hosts remain at changed=0.

Closes a real gap in the §5 procedure: **step 0 as written only exercises the HTTP API, which is the portal's path.** Forgejo, Alertmanager and the monitoring cross-probe all send over **SMTP** — a different credential with its own authorisation list. Step 3 repoints `forgejo_mailer_from`, `alert_email_from` and `monitoring_probe_mail_from` at the new domain, so SMTP must authorise it too, and an API pass says nothing about that. ## Verified after the credential rotation (#385) From **both** hosts, since Alertmanager sends from the monitoring VM with its own egress. Mirrors the cross-probe's own curl invocation, so a pass here means that probe will work. | sender | services host | monitoring host | | --- | --- | --- | | `alerts@mail.gitborg.se` | `rc=0` | `rc=0` | | `no-reply@email.bitborg.se` | `rc=0` | `rc=0` | **Step 3's SMTP prerequisite therefore holds.** ## With controls, because four rc=0 results are not evidence | control | result | proves | | --- | --- | --- | | unauthorised sender domain + correct password | `rc=8` "Weird server reply" | the relay **does** enforce the sender | | known-good sender + wrong password | `rc=67` "Login denied" | AUTH **is** exercised | Without these, the `email.bitborg.se` pass would be equally consistent with a relay that accepts anything — which would have made it worthless as a step 3 prerequisite. Same discipline that caught `/channels` answering 200 while completely unauthenticated in #385. Docs only; no behaviour change. Both hosts remain at `changed=0`.
supernaut lade till 1 incheckning 2026-08-05 20:01:32 +00:00
docs(mail): record that the SMTP path is verified for both domains
Alla kontroller lyckades
ci / ci (pull_request) Successful in 18s
6367b9ad18
Step 0 as written only exercises the HTTP API, which is the portal's path.
Forgejo, Alertmanager and the monitoring cross-probe all send over SMTP -- a
different credential with its own authorisation list -- and step 3 repoints
forgejo_mailer_from, alert_email_from and monitoring_probe_mail_from at the new
domain. So an API pass says nothing about whether step 3 will work, which was a
real gap in the procedure.

Verified after the rotation from both hosts (Alertmanager sends from the
monitoring VM with its own egress), mirroring the cross-probe's own curl: both
the current sender and no-reply@email.bitborg.se return rc=0 on both hosts, so
the step 3 prerequisite holds.

Records the two negative controls alongside, because four rc=0 results are not
evidence without them: an unauthorised sender domain with the correct password is
rejected rc=8, and a known-good sender with a wrong password is rejected rc=67.
Together those prove the relay enforces the sender AND that AUTH is exercised.
supernaut sammanfogade incheckning 66db9be782 till main 2026-08-05 20:02:38 +00:00
Logga in för att delta i denna konversation.
Inga granskare
Ingen milstolpe
Inget projekt
Inga tilldelade
1 deltagare
Notiser
Förfallodatum
Förfallodatumet är ogiltigt eller utanför gränserna. Använd formatet "åååå-mm-dd".

Inget förfallodatum satt.

Beroenden

Inga beroenden satta

Referens
bitborg/bitborg-infra!386
Ingen beskrivning angiven.