fix(spam): stop blocking signups whose address is initials then digits - #564
Merged
Merged
Conversation
A reporter could not register: checkEmail refused their long-established
personal Gmail address with "Email matches spam pattern" and no appeal route.
They sent a minimal reproduction — checkEmail("abc123456789@example.com")
returns { spam: true } — and noted that PR #549 changed plus-tag handling but
left this rule untouched.
The rule was /^[a-z]{2,3}\d{6,}@/i in SPAM_EMAIL_PATTERNS, meant to catch
ab123456@. Initials followed by digits is one of the most ordinary ways a real
address is formed: a birth year, a phone fragment, digits of pi. The shape
alone says nothing about who typed it, and unlike a username — which a blocked
signup can simply pick differently — an email address is the one they have, so
a false positive here is a closed door rather than an inconvenience.
This is the same correction #549 made to the plus-tag length rule and #531 made
to the username shape heuristics: what marks a generated address is randomness,
not the presence of digits after letters. The remaining /^[a-z0-9]{20,}@/i
still catches long random local parts, and the disposable-domain set and
generated-tag test are untouched.
The test that asserted ab123456@example.com is spam now asserts it is allowed,
alongside the reported shape and three other real-world ones.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan45 finding(s) HIGH/CRITICAL: 1 | MEDIUM: 8 | LOW: 36
Snippets are redacted; ThreatCrush never prints matched credential material. |
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.
Reported by email
Someone emailed
hello@ugig.net(2026-09-13, subject "Signup blocked by email spam-pattern check") because they could not register.checkEmailrefuses their long-established personal Gmail address with"Email matches spam pattern"and offers no appeal route.They included a minimal reproduction:
and noted that #549 changed plus-tag handling but left this rule untouched — which is correct, it is a separate rule.
The rule
Initials followed by digits is one of the most ordinary ways a real address is formed: a birth year, a phone fragment, digits of pi. The shape alone says nothing about who typed it.
It also fails asymmetrically. A username caught by a shape heuristic can be picked differently; an email address is the one the person has, so a false positive here is a closed door, not an inconvenience.
The fix
Drop that pattern. This is the same correction made twice before in this file:
Each time the conclusion was the same: what marks a generated address is randomness, not a shape. The remaining
/^[a-z0-9]{20,}@/istill catches long random local parts, and the disposable-domain set and generated-tag test are untouched —x7f2q9k1m4z8p3w6r5t0@example.com,someone+x7f2q9k1m4z8@gmail.comandsomeone@mailinator.comare all still blocked.Tests
The case that asserted
ab123456@example.comis spam now asserts it is allowed, alongside the reported shape and three other real-world ones (initials + date of birth, initials + phone fragment, initials + digits of pi). Verified all 14checkEmailcases behave as asserted.Notes for follow-up (not in this PR)
SPAM_USERNAME_PATTERNShas the same shape rule for usernames (/^[a-z]{2,4}\d{5,}$/i), mirrored in five SQL migrations. Left alone: a username can be chosen differently, and the reporter was blocked on email. Worth a look if signups keep bouncing.🤖 Generated with Claude Code