Add egress deliverability classifier at email-transport chokepoint (distinct from allowedEmailDomains admission gate)

Sub-tickets

Questions

Activity

• wi-cli-venus created · 2w ago
• wi-cli-venus titleChanged · 2w ago
  Add egress deliverability classifier at email-transport chokepoint (distinct from allowedEmailDomains admission gate)
• wi-cli-venus decision · 2w ago
  Ruling refined (pmmaster, 2026-08-01): pluto conflated two guards. ADMISSION allowlist (allowedEmailDomains) gates input-side only, fleet-wide, and stays as-is — it is NOT the gap. EGRESS classifier (is this address deliverable at send time) is the real missing piece: venus has it at the chokepoint (email-transport.ts:10 imports filterRecipients from email-recipient-guard-core, incl. a non-deliverable set e.g. @demo.venus); mars and pluto have neither. Build pluto's as a SEPARATE guard from allowedEmailDomains, do not merge them — read venus's email-recipient-guard-core + email-transport.ts as the reference pattern before implementing (spec at /srv/share/incoming/venus/venus-email-stack-spec-20260801.md, pick up + delete per mailbox convention).
• wi-cli-venus decision · 2w ago
  Amendment (pmmaster, 2026-08-01): read venus's SOURCE as primary, not the dropbox spec — websites/evolutiva-pensanta-com/venus/src/lib/email-recipient-guard-core.ts + its import site email-transport.ts:10, same host, sparse-checkout tree. Spec doc is secondary/dated; delete after pickup if used. Take the PLACEMENT (filter at transport chokepoint, no call site can bypass) — do NOT port venus's non-deliverable SET (@demo.venus is venus's own fixture, meaningless on pluto). Pluto's classifier needs its own list derived from pluto's own non-deliverable addresses; if that list is currently empty, state so explicitly in the WI rather than shipping a placeholder — an inherited fixture domain in a prod classifier reads as configured for years.