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.
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.