Verify: recognize Google Workspace (gappssmtp) signers, explain Microsoft 365 tenants

[Divide-By-0]

Why

#26 made the verify page and CLI verify require the From: domain to match the DKIM signing domain (d=), which is right for a mailing service signing with its own domain. Two very common platforms sign customer mail with their domain when the customer hasn't set up DKIM:

Platform	d=	Can it be tied to the From: domain?
Google Workspace	<from-domain, dots→dashes>.<yyyymmdd>.gappssmtp.com	Yes, for one-dot domains (bank.example): the label is the customer's domain. For longer domains it is ambiguous (see below)
Microsoft 365	<tenant>.onmicrosoft.com	No: tenant names aren't derived from domains, and a tenant's domains aren't public

Typical case: an organisation's mail (From school.example) is signed by school-example.20150623.gappssmtp.com and, on other messages, by school.onmicrosoft.com. Before this PR both showed the amber "From: not proven" banner, and the CLI exited 5.

What changes

• signerProvider(fromDomain, d), in both the site and the CLI, recognises the two platforms.
• Google Workspace, tenant label = dashed From: domain: the From: line now counts as proven via Google Workspace.
  • The page shows a green banner naming Google: "Signed by Google Workspace for school.example…".
  • CLI verify exits 0 and reports fromAlignedVia: "google-workspace".
• Google Workspace, other tenant: stays amber, and the banner says the Workspace doesn't match the From: domain.
• Microsoft 365: stays amber. The warning now explains it is a Microsoft 365 tenant and why that can't be tied to the From: domain.
• Ambiguity: turning dots into dashes is not one-to-one (bank.co.uk and bank-co.uk both become bank-co-uk), and Workspace's SMTP relay can be set to send any From: address. So only one-dot From domains count as proven, since a TLD can't contain a plain hyphen. Longer domains stay amber with an explanation of why. zk-email-verify#324 keeps gappssmtp opt-in for the same reason.
• Microsoft 365: there is precedent for treating it as unproven: email-wallet#80 shows a Microsoft 365 tenant signing for an unrelated From domain.

Tests

• tests/key-binding.test.ts: 3 new tests (with ambiguous-domain cases) covering signerProvider (site and CLI), the Google banner (fails on main, which shows a warning) and the Microsoft banner. Full suite: 47/47 under Node 20, the CI version.
• Separate, pre-existing issue: real proofs … (CLI exit codes) from Security fixes: DKIM key binding on verify, canonical outputs, c=simple redactions, From alignment, no proof overwrite #26 fails locally under Node 22.22 (stubbed DNS returns "no key found") and passes under Node 20. CI uses 20; I'll look at it separately.

Not fixable here

• Older Google Workspace mail is unverifiable today. Google retired the 2015 gappssmtp signing keys, which no longer resolve in DNS, and archive.prove.email doesn't track gappssmtp.com subdomains.
• Fix suggested for the archive service: record the keys behind *.gappssmtp.com, which current tenants serve through a DNS wildcard.

🤖 Generated with Claude Code

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: 02dd639d-0620-4a3d-8745-6f41eb7e5888

📥 Commits

Reviewing files that changed from the base of the PR and between 7313499 and 50b754f.

📒 Files selected for processing (5)

• .agents/skills/redacted-circuit-maintenance/SKILL.md
• skills/redacted-email-proof/SKILL.md
• skills/redacted-email-proof/scripts/redacted.mjs
• src/utils/keyBinding.ts
• tests/key-binding.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

Verification now recognizes Google Workspace and Microsoft 365 signing domains. A matching Google Workspace tenant label can establish From alignment; Microsoft 365 tenant recognition does not. Verification metadata and messages report provider and alignment details. Two skill notes also received wording updates.

Changes

Signer provider alignment

Layer / File(s)	Summary
Provider recognition and alignment rules src/utils/keyBinding.ts, skills/redacted-email-proof/scripts/redacted.mjs	Both implementations recognize Google Workspace and Microsoft 365 signing domains. Google Workspace alignment requires the tenant label to match the dashed From domain.
Binding metadata and verification messages src/utils/keyBinding.ts, skills/redacted-email-proof/scripts/redacted.mjs, tests/key-binding.test.ts	Matched-key results record alignment and provider details. Verification messages distinguish Google Workspace alignment and unaligned Google Workspace or Microsoft 365 signing. Tests cover provider recognition and these outcomes.

Skill note wording updates

Layer / File(s)	Summary
Incident and benchmark note wording .agents/skills/redacted-circuit-maintenance/SKILL.md, skills/redacted-email-proof/SKILL.md	The incident note removes an Amazon/SES attribution. The benchmark example changes from a PayPal receipt to a generic 34 KB receipt; reported measurements remain unchanged.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to 50b75

The change recognizes Workspace alignment and explains Microsoft 365 signers while preserving ordinary domain alignment. No merge-blocking failure was established; whether Google relay signing permits a colliding-domain false verification remains unproven.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 50b75

Existing cryptographic proof and published-key checks remain in place. The new Google Workspace acceptance rule nevertheless depends on a provider identity guarantee that has not been established for SMTP relay configurations. No exploitable false verification has been demonstrated.

Retained concerns

• Low · security · inferred: The new Google Workspace authenticity decision relies on an unresolved provider enforcement guarantee. Different From domains can produce the same dashed tenant label. If Google permits a colliding-domain customer to obtain the relevant fallback signature over an external From address, both verifiers would accept that address as aligned. The required delivered-message behavior remains unproven; this is a conditional trust-boundary concern, not a verified exploit.

Security review details

Security Blast Radius

• inferred — The conditional exposure spans matching Google fallback-signature proofs accepted by either verifier, rather than one configured customer domain. The inspected outcomes are browser authenticity status and CLI verification metadata and acceptance; downstream authorization effects are not established.

Security Findings and Attack Paths

• inferred — A possible attack requires more than attacker-chosen headers or a self-generated key: it requires obtaining a genuine, matching Google fallback signature for an external From identity that collides under the label transformation, then producing a valid proof. The canonical candidate remains deferred because that provider behavior has not been demonstrated.

Trust Boundaries and Controls

• observed — Provider recognition does not independently bypass proof validity or published-key matching. The browser rejects invalid and legacy proofs before binding; unmatched keys cannot produce verified status. The CLI retains separate failure exits for invalid proofs, unmatched keys, legacy proofs, and unaligned From identities.

Resilience and Maintainability Implications

• observed — Browser key binding keeps its hash cache local to each invocation, attempts DNS before archive lookup, and tolerates individual lookup failures without marking the result matched. Provider alignment is attached only on a successful key-hash match.

Hardening Proposals

• proposed — Resolve the provider guarantee with delivered-message evidence covering colliding domains, external visible From addresses, “Any addresses” relay mode, and fallback signing. Until that guarantee is established, conservative Google provider recognition without authenticity promotion is a possible policy choice.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 3 files. (2 skipped: …	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main changes: recognizing Google Workspace gappssmtp signers and explaining Microsoft 365 tenant domains.

Full details: Docstring Coverage

Explanation

Docstring coverage is 60.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 10 functions across 3 files. (2 skipped: 2 unsupported.)

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Autopilot is currently an internal CodeRabbit preview.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}