At least during registration, the email address validation function rejects valid addresses (like mine, preventing me from registering). In validateEmail in admininvite.js, the regexp /^[a-zA-Z]+[a-zA-Z0-9.-]+@[a-zA-Z0-9_.-]+[a-zA-Z]$/ incorrectly rejects addresses which (a) have user portions only one character long, and/or (b) begin with something other than a letter. Neither is a valid restriction. A close approximation of a fix is simply removing the leading "[a-zA-Z]+"; I think the remaining regexp is still overly strict, but at least the corner case becomes a lot smaller corner.
The only genuinely prohibited ascii printable characters are space and "specials", per RFC822 (and updates): ()<>@,;:\"[]
(Edit: removed . as while it's a "special", it's explicitly allowed elsewhere.)
I can't tell what validation is performed on email addresses beyond registration; the same error should be checked for there.
tassoman
commented
1 year ago
At least during registration, the email address validation function rejects valid addresses (like mine, preventing me from registering). In validateEmail in admininvite.js, the regexp /^[a-zA-Z]+[a-zA-Z0-9.-]+@[a-zA-Z0-9_.-]+[a-zA-Z]$/ incorrectly rejects addresses which (a) have user portions only one character long, and/or (b) begin with something other than a letter. Neither is a valid restriction. A close approximation of a fix is simply removing the leading "[a-zA-Z]+"; I think the remaining regexp is still overly strict, but at least the corner case becomes a lot smaller corner.
The only genuinely prohibited ascii printable characters are space and "specials", per RFC822 (and updates): ()<>@,;:\"[] (Edit: removed . as while it's a "special", it's explicitly allowed elsewhere.)
I can't tell what validation is performed on email addresses beyond registration; the same error should be checked for there.