Broader angle: free SMTP relay for any purpose - found manually 2026-08-30

[msgwing]

CEO asked for the net to widen beyond printers/O365 error codes to "anyone on GitHub publicly asking for a free SMTP relay for any purpose" - homelab, self-hosted apps, side projects, monitoring/notification scripts. This issue records a manual search done today against that broader angle, separate from #354/#358 which were both still inside the existing O365/5.7.139 angle.

Method: gh search issues, GitHub's GraphQL search(type: DISCUSSION) (the automated bot never queries this - more on that below), and the Stack Exchange advanced-search API, run by hand, not through the workflow.

Candidates worth a qualifier's attention

• Taxcursor/appealdesk#69 - "[Feature]: Supabase New Paid SMTP server", opened 2026-08-10, open, zero comments. Real project hit Supabase's built-in free SMTP cap (2 emails/hour) on password-reset mail and is about to pay for a paid SMTP service instead. Genuinely the broader angle - no O365, no printer. Needs a check before drafting: does their signup/reset mail have to come from their own domain? The issue doesn't say. If it doesn't, this is a clean fit; if it does, ZeroSMTP is the wrong answer per our own rule and the honest reply says so.

• rcourtman/Pulse discussions#1523 - not postable (closed 2026-07-11, resolved with a Discord webhook instead of SMTP), but worth recording as market signal rather than as a lead: a homelab user of a 6,643-star Proxmox/TrueNAS monitoring tool wrote, verbatim, "I didn't have an SMTP server to ship to, I wasn't going to hook it up to Google or SMTP2GO which could eventually incur dollars." That is the exact user ZeroSMTP is built for, on a real, popular, homelab-monitoring tool. Nothing to post here - the thread moved on - but it's evidence the broader angle is real and where it concentrates (monitoring/notification tools, not printers).

• djraj/lotus-rewards-app#33 - a self-authored "watch item" noting Brevo's free 300/day SMTP cap as a future scaling risk, not an active ask. Weak/borderline - flagging for awareness, not recommending a reply since nobody is asking anything yet.

Recurring false-lead pattern found today - do not re-investigate these

Four separate hand-searches turned up people asking for an unauthenticated SMTP relay/smarthost - the opposite of what ZeroSMTP offers, since ZeroSMTP always requires SMTP AUTH with a username and password:

• stumpapp/stump#1083 - "Support authless smtp relay"
• YunoHost/issues#2189 - "Impossible to use unauthenticated SMTP relay"
• pocketbase/pocketbase discussions#6868 - "How to setup pocketbase to send mails with a plain SMTP relay?" (no auth, no TLS)
• docker-mailserver discussions#4559 - already resolved at length in-thread by a maintainer, and the asker explicitly wants to self-host their own small relay container, not use a hosted one.

Conclusion for the automated workflow - no change made, and why

outreach-watch.yml's queries and its two-sided gate (DECISIVE or MAIL+AUTH) are built entirely around the O365/basic-auth-deprecation angle. They do not catch this broader angle, at two separate levels:

1. No query targets it. The three GH_QUERIES all require an O365/printer-flavoured term in the title. None would have matched Taxcursor/appealdesk#69.
2. The gate would drop it anyway. Taxcursor/appealdesk#69's title contains smtp (a MAIL hit) but no AUTH term and no DECISIVE string - onTopic() returns false. The gate is correctly narrow for what it was built to filter (see the six false positives from 2026-08-17 in the workflow's own comments), but that same narrowness excludes the broader ask by design.

I measured before proposing anything, per the tuning process this file requires, and the numbers don't clear the bar:

• GitHub issue search, bare token "free smtp" (30 results): ~3-4 genuinely on-topic out of 30, and the rest is unrelated app tickets (email verification, mass-mailer feature requests, a spoofing tool) - about 10-13%.
• GitHub Discussions, "recommend" "smtp relay" (top 20 of 53): 1 genuinely good hit, already answered in-thread - 5%.
• GitHub Discussions, "smtp" homelab free (all 10 of 10): 2 on-topic (Pulse, docker-mailserver above), both already resolved/closed - 0 that are open and actionable.
• Stack Exchange, the existing free smtp relay query with no date filter on serverfault/superuser: matches on bare tokens free + smtp + relay anywhere, returns old unrelated postfix/DNS questions from 2014-2023, none of them someone asking for a relay recommendation.

All four are well under the "roughly a third" bar this file sets for adding a new signal, so no query or gate change is going in. The one specific, measurable gap - GitHub Discussions is a surface the bot has never searched, and it's where the real "what should I use" conversations concentrate - stays a documented gap rather than a change, because even hand-picked queries against it didn't clear the bar. If someone finds a Discussions query that does, that's the next thing to try, not a looser gate on the existing Issues search.

Nothing has been posted anywhere. Closing this once triaged, same as #354/#358.

[msgwing]

Update from outreach-qualifier's closer read: Taxcursor/appealdesk#69 is disqualified. Two independent reasons, either one alone is sufficient:

1. Not an auth-method problem. The blocker is Supabase's built-in free-tier cap of 2 emails/hour, not a refused authentication method. ZeroSMTP answers "the server won't accept how I'm authenticating"; it does not answer "the server accepts me but limits how much" - and its own cap is 200/day, so a volume complaint usually isn't even solvable by switching to it.
2. Client-facing, branded mail. The emails in question are password resets and invites sent to appealdesk's own end customers under appealdesk's identity - that needs their own domain even though the issue never uses the word "domain". A shared @msgwing.com sender would be the wrong answer here regardless of point 1.

Both criteria are now explicit in outreach-qualifier.md's qualification gate (items 2 and 4), with this exact issue kept as the worked example, so a future sweep doesn't have to re-derive it. Relevant for the planned 2026-09-06 broader GitHub Discussions/Reddit search too - quota/rate-limit complaints and branded-client-mail cases will recur there.

Remaining candidates in this issue (Pulse discussion - market signal only, not postable; lotus-rewards-app#33 - weak/borderline, nobody actively asking) are unaffected by this and stand as originally written.