Guard addresses live at names.moshcode.sh, and the DNS exists - #445
Merged
Conversation
…exists Guard addresses were designed against `@moshcode.sh` and the apex was the wrong answer twice over. `pit.moshcode.sh` — the obvious subdomain — cannot carry mail at all: it is a CNAME to Railway, and a CNAME may not coexist with an MX at the same name. That is a DNS rule, not a configuration choice. The apex would have worked, since Porkbun's ALIAS is a flattened A rather than a real CNAME. But it would put the reputation of forwarded stranger mail on the same name as any staff mail moshcode.sh ever carries, and forwarding is the hardest deliverability case there is. It gets a name of its own to damage. So: names.moshcode.sh. The records are live and verified authoritative — MX to mx1/mx2.forwardemail.net, SPF, and a report-only DMARC, added through the Porkbun API. `pit.` and `app.` are untouched. Nothing had to be migrated because nothing had been published: no alias can be minted without FORWARDEMAIL_API_KEY, so every contact is still `pending` and no address exists anywhere to be invalidated. This was the last moment the choice was free. The doc also records two things that cost time to work out. The Porkbun credentials are in the logicsrc shared vault, not absent as previously written. And a bare `dig` on this box goes to the Moshpit DNS bridge, which answers for every *.moshcode.sh name with a synthesised record — it will tell you a host exists when public DNS has never heard of it. Always `@1.1.1.1`. Still outstanding, and both need a person: adding names.moshcode.sh to the Forward Email account with its verification TXT, and putting the resulting API key on the Railway service. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017QSp1aAoQQB7jFV7hwt4jJ
ThreatCrush Security Scan0 finding(s) in the 3 file(s) this pull request changes. Nothing in the files this pull request changes. 81 pre-existing finding(s) elsewhere in the repository — **HIGH/CRITICAL**: 5 | **MEDIUM**: 67 | **LOW**: 9Not introduced by this pull request. The full set is in the Security tab.
…and 61 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Guard addresses were designed against
@moshcode.sh. The apex turned out to be the wrong answer twice over, and this fixes it while the choice is still free — nothing has been published, because no alias can be minted withoutFORWARDEMAIL_API_KEY, so every contact is stillpendingand no address exists anywhere to invalidate.Why not
pit.moshcode.shIt's a CNAME to Railway, and a CNAME may not coexist with an MX at the same name. That's a DNS rule, not a configuration choice — mail there is impossible.
Why not the apex
It would have worked: Porkbun's ALIAS is a flattened A, not a real CNAME. But it puts the reputation of forwarded stranger mail on the same name as any staff mail
moshcode.shever carries, and forwarding is the hardest deliverability case there is. It gets a name of its own to damage.DNS — done and verified authoritative
Added through the Porkbun API and confirmed against
@salvador.porkbun.com.pit.andapp.are untouched —pit.moshcode.shstill resolves to Railway and still serves 200.DMARC is
p=nonedeliberately: report only, since an aggressive policy bites a forwarder first and nothing should be quarantined while the setup is unproven.Two things the doc now records, because both cost time
The Porkbun credentials exist.
PORKBUN_API_KEY/PORKBUN_SECRET_API_KEYare in the logicsrc vaultprofullstack-sharable-keys--prod. A previous note said DNS changes here were a hand-off with no credentials available; that was wrong.A bare
diglies on the dev box. The resolver is the Moshpit DNS bridge, which answers for every*.moshcode.shname with a synthesised record. It reported a wildcard that does not exist and will happily tell you a host is live when public DNS has never heard of it. Alwaysdig ... @1.1.1.1.Still outstanding — both need a person
names.moshcode.shto the Forward Email account, add theforward-email-site-verification=…TXT it issues, and confirm the plan covers API alias management.FORWARDEMAIL_API_KEYon themoshcodeRailway service.Until then the feature stays inert rather than broken, exactly as before: contacts are recorded,
alias_statusstayspending,/pit/contactsays plainly that no mail host is configured, and nothing is published on any name.Suite: 709 passing, 0 failing.
🤖 Generated with Claude Code
https://claude.ai/code/session_017QSp1aAoQQB7jFV7hwt4jJ