Reddit + cross-repo GitHub Discussions - checked 2026-08-30 ahead of the 09-06 board deadline

[msgwing]

Board set 2026-09-06 as the result deadline for two surfaces neither the bot nor a manual pass had checked before today: Reddit (r/sysadmin, r/msp, r/exchangeserver via the .json trick) and GitHub Discussions in repositories other than our own. This issue records that check, run today rather than waiting for the deadline. Same rigorous criteria as #365 and the four query variants tested earlier today: the existing two-sided gate (DECISIVE, or both a MAIL and an AUTH hit; SKIP overrides both), and the same "roughly a third" bar before anything gets added to a workflow.

Reddit — could not be measured, not measured-and-empty

Tried three independent channels, all blocked:

• curl to www.reddit.com/r/sysadmin/search.json?... → HTTP 403 (Cloudflare challenge page, not JSON).
• curl to old.reddit.com/r/sysadmin/search.json?... and old.reddit.com/r/sysadmin/new.json → HTTP 302 to /login/?reason=lor2. Reddit now requires an authenticated session for these endpoints from this network; the "add .json to the URL" trick this was scoped on no longer works unauthenticated.
• Browser navigation to the same URL → refused outright: "reddit.com is blocked by policy."
• WebFetch on the same URL → refused: "Claude Code is unable to fetch from www.reddit.com."

Per the handbook's own rule ("silence and outage look identical... must fail loudly when it could not look"), this is not a zero. Nothing about Reddit's actual content is known from this session either way. Closing the loop needs one of: a Reddit API app (OAuth client credentials, not the anonymous .json route), or a human checking manually in a logged-in browser before 09-06. Flagging this as a gap for change-board / whoever owns the 09-06 deadline, not something discovery-tuner can resolve with the tools this role has.

GitHub Discussions, other repositories — measured, below the bar, one candidate

Ran the bot's own three GH_QUERIES (5.7.139, "basic authentication is disabled", smtp free relay) unchanged, through gh api graphql against search(type: DISCUSSION, first: 20), excluding -repo:msgwing/ZeroSMTP. This is a different query set from #365's Discussions pass today ("recommend" "smtp relay" and "smtp" homelab free), so it's new coverage of the same surface rather than a repeat.

Applied the workflow's exact onTopic() gate to each title, plus the same GH_MAX_IDLE_DAYS = 120 freshness rule the workflow already applies to GitHub issues (a thread nobody has touched in four months is dead even when open — extending that same rule to Discussions rather than inventing a new one):

query	raw results	gate-pass (title)	gate-pass AND fresh (<120d)
5.7.139	16	7 (44%)	1 (6%)
"basic authentication is disabled"	15	2 (13%)	0 (0%)
smtp free relay	20	1 (5%)	1 (5%)
combined	51	10 (20%)	2 (4%)

Both below the ~1/3 bar, and the raw title-gate number for the first query is inflated by threads that only look fresh because of an unrelated spam comment bumping updatedAt — see below. No change going into outreach-watch.yml or listings-radar.yml. GitHub Discussions cross-repo, checked twice today with two different query strategies, produces the same low yield both times.

Of the 2 that pass both the gate and the freshness filter:

• pocketbase/pocketbase#6868 — already identified and disqualified in Broader angle: free SMTP relay for any purpose - found manually 2026-08-30 #365 today as the recurring "wants an unauthenticated SMTP relay" false-lead pattern (ZeroSMTP always requires SMTP AUTH). Checked the actual thread content again to be sure: original ask and the one useful reply are both from 2025; the only 2026 activity is a one-word (Ad) spam comment, which is what made it look fresh by updatedAt alone. Not re-flagging, confirms Broader angle: free SMTP relay for any purpose - found manually 2026-08-30 #365's disqualification rather than adding a new one.

• simonrob/email-oauth2-proxy#405 — new today, not caught by Broader angle: free SMTP relay for any purpose - found manually 2026-08-30 #365's queries. "Free outlook account SmtpClientAuthentication is disabled for the Mailbox outlook erroo" — a real, literal 535 5.7.139 report, most recent comment 2026-07-03 (well inside the freshness window). Already marked answered: the repo's own maintainer replied "There's no way around this, so your only option is to either use another service, or switch to a provider that uses Microsoft Graph instead... I know Auth-Email offers this; there may also be others." — an explicit invitation to name an alternative, which is exactly the shape of thing ZeroSMTP could be the honest answer to.

  Flagging loudly rather than deciding: this thread lives inside a direct competitor's own repository — simonrob/email-oauth2-proxy, 1466 stars, already the top row in this project's own competitive-intel table (ALTERNATIVES.md) — and the reply would land immediately after that project's own maintainer answered. That is a different kind of judgment call than replying on Stack Exchange or in an unrelated project's issue, and it belongs to outreach-qualifier / trust-safety, not to this role. Also unchecked: whether the asker needs the From address on their own domain (not stated in the thread) — the same check Broader angle: free SMTP relay for any purpose - found manually 2026-08-30 #365 already flagged as required before drafting Taxcursor/appealdesk#69.

  Nothing has been posted. This is a candidate for triage, not a draft ready to go out.

Conclusion

Reddit: unmeasured, needs different access than this role has. GitHub Discussions cross-repo: measured twice today with two query strategies, consistently below the bar for a workflow change, one individual candidate worth a qualifier's look with the competitor-repo caveat attached. Marking stan:w-pracy for that one triage item rather than closing outright.