check.milter: fail_open does not cover a milter session-dial failure
- Langage dominant
- Go
- Étoiles
- 6.1k
- Forks
- 327
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
## Summary
`check.milter`'s `fail_open` directive is documented to let a message through when the milter can't be consulted, but it silently doesn't cover one specific failure mode: the milter being completely unreachable when maddy tries to establish a session.
## Root cause
`CheckStateForMsg` (`internal/check/milter/milter.go`) dials the milter backend via `c.cl.Session()` and returns any error unconditionally. This happens *before* a `*state` exists, so the failure never reaches `ioError()` — the only place `fail_open` is actually checked. Result: with `fail_open` set, a message is still hard-rejected (a real SMTP-level error handed back to the original sender) if the milter is simply down — exactly the case `fail_open` exists to guard against.
## Reproduction
Configure `check.milter` with `fail_open: true` pointing at a milter address that's genuinely unreachable (e.g. nothing listening on that port), then send a message through. Expected: message accepted unchecked, per `fail_open`. Actual: a hard SMTP-level rejection.
## Fix
I've prepared and tested a fix — handles the dial failure the same way `ioError()` already handles a later I/O failure — and opened it as #865, with a regression test that fails against unpatched code and passes with the fix.
Apologies for the PR arriving before this issue — I realize CONTRIBUTING.md's process is to raise the issue first. Filing this now so there's a proper place to discuss the bug alongside the PR.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Lisez internal/check/milter/milter.go, en particulier CheckStateForMsg et la gestion existante de ioError. Examinez le test de régression mentionné dans PR #865 et vérifiez qu’un milter inaccessible avec fail_open activé accepte le message sans le vérifier, tandis que le test réussit.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- go
- Domaine
- backend
- Type d'issue
- Bug
- Difficulté
- 2/5
- Temps estimé
- 1-3 heures
- Activité
- À l'abandon
- Clarté
- Clairement spécifiée
- Accessibilité débutants
- 25/100