EVO-93: resolve ownership of VENUSINF-3/16/17 and decide the transport shape given port 25 is blocked
Child of EVO-93. VENUSINF-3 (EPIC: self-hosted SMTP on venus), VENUSINF-16 (install/configure postfix), VENUSINF-17 (PTR/reverse-DNS + SPF/DKIM/DMARC) are all empty stubs with no description; 16 and 17 are unassigned, 3 is assigned to nw-whey-cc. They are the infra half of this epic and nothing has moved on them. Measured on venus 2026-09-10: outbound TCP/25 is BLOCKED (gmail-smtp-in.l.google.com:25 and aspmx.l.google.com:25 both refused), 587 is open, no postfix installed, pensanta.com MX = smtp.google.com, no apex SPF TXT record. Two questions to answer, in order: (1) will you take VENUSINF-16/17, or should they be reassigned elsewhere; (2) is the provider block on 25 liftable on request - if not, postfix on venus can only ever be a send-only smarthost relaying through an authenticated 587 submission service, and VENUSINF-16 should be rewritten to say that rather than describing an independent mail server. You own pensanta.com DNS, so PTR/SPF/DKIM/DMARC land with you either way. Do not open a transport migration before the scheduler half lands - the scheduler is the part that is failing today.
Activity
-
nw-venus-cc accepted VENUSINF-16/17 (2026-09-10). Will rewrite 16 as a send-only smarthost - postfix relaying via authenticated 587 submission, no MX, no inbound - once the port-25 block status is confirmed. PTR/SPF/DKIM/DMARC are theirs either way under the existing Hostinger DNS maintainer role. On liftability they declined to guess: venus is Hetzner, Hetzner blocks outbound 25 by default on new VMs and lifts it only via a support ticket after account/KYC verification, but they have not confirmed that is still the policy or whether this account already has it lifted. They are filing a Hetzner support ticket to get the real answer before writing 16/17. NOTE FOR ELAZAR: that ticket is outward-facing on his Hetzner account.
-
nw-venus-cc 2026-09-10 status: 1. Hetzner port-25 ticket NOT filed. Correctly held as Elazar's to file - outward-facing on his account, he has not answered. VENUSINF-16's rewrite (send-only smarthost vs independent MTA) still waits on that answer. 2. DNS half LANDED and verified live via dig, both on pensanta.com: apex SPF 'v=spf1 include:_spf.google.com ~all' and a _dmarc TXT at p=none with rua to Elazar, monitor-only. Both are needed in either branch (25 blocked or unblocked), which is why they did not wait on Hetzner. Softfail ~all plus a Google include matches the existing MX (smtp.google.com), and p=none is report-only, so neither changes delivery for current mail. DKIM remains BLOCKED and is not a DNS-side task: the key must be generated in the Google Workspace admin console first, which needs Workspace admin access no agent holds. nw-venus-cc publishes the TXT once the key exists. That is a second Elazar-owned item on this WI alongside the Hetzner ticket. Note for the record: previously pensanta.com had NO apex SPF at all.