Valid email addresses are rejected with `The email address is invalid`, entirely preventing the use of gitea

[throwaway-2e119d4c79e4b162f4]

Description

Valid email addresses are rejected, preventing admin user, or any other user, creation; additionally, these same valid email addresses are rejected if a temporary one is added and attempted to fix with the valid one after the fact.

Example address that is not accepted, despite being perfectly valid under (among other standards):

• RFC 5322 https://datatracker.ietf.org/doc/html/rfc5322
• RFC 3696 https://datatracker.ietf.org/doc/html/rfc3696

Without quotes, local-parts may consist of any combination of
   alphabetic characters, digits, or any of the special characters

      ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

   period (".") may also appear, but may not be used to start or end the
   local part, nor may two or more consecutive periods appear.  Stated
   differently, any ASCII graphic (printing) character other than the
   at-sign ("@"), backslash, double quote, comma, or square brackets may
   appear without quoting.  If any of that list of excluded characters
   are to appear, they must be quoted.  Forms such as

      user+mailbox@example.com

      customer/department=shipping@example.com

      $A12345@example.com

      !def!xyz%abc@example.com

      _somename@example.com

   are valid and are seen fairly regularly, but any of the characters
   listed above are permitted.  In the context of local parts,
   apostrophe ("'") and acute accent ("`") are ordinary characters, not
   quoting characters.  Some of the characters listed above are used in
   conventions about routing or other types of special handling by some
   receiving hosts.  But, since there is no way to know whether the
   remote host is using those conventions or just treating these
   characters as normal text, sending programs (and programs evaluating
   address validity) must simply accept the strings and pass them on.

Example:

_@anydomain.com

Gitea Version

v1.16.8

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

not relevant

Database

MySQL

[throwaway-2e119d4c79e4b162f4]

This issue has been raised before, and closed as completed, but clearly, it is not

#17029 (comment)

#17029 (comment)

I don't think it makes sense for gitea to validate emails at this point. AFAIK these emails serve two purposes:

    Send email notifications
    Associate the user with the emails in git histories

https://davidcel.is/2012/09/06/stop-validating-email.html

https://medium.com/hackernoon/the-100-correct-way-to-validate-email-addresses-7c4818f24643

The 100% correct way

Send your users an activation email. (That’s a bold full-stop for effect.)

If you are not going to send a validation email, then do not try to validate the email address; don't reject valid email addresses you haven't validated, because you cannot know they are invalid if you haven't tested their validity by verifying they are valid...

[throwaway-2e119d4c79e4b162f4]

Just bumping this to ensure it was seen; github (the platform itself) marked the issue as invalid, hid it, and locked my account for two weeks as a result

[6543]

that's stupid agree

[lunny]

I think yes, recent version has a more restricted limitation for email address than any RFC. For your example, both user+mailbox@example.com and customer/department=shipping@example.com are valid email addresses.

[wxiaoguang]

Plus since 2012 you can use international characters above U+007F, encoded as UTF-8.

https://stackoverflow.com/questions/3844431/are-email-addresses-allowed-to-contain-non-alphanumeric-characters

(just FYI, not sure whether Gitea should support it. there could be some comments or documents about supporting or not).

[6543]

I wold not allow all UTF-8 but more ASCI chars like _

[lunny]

Currently capital char is only allowed with [0-9a-zA-Z], that why $A12345@example.com, !def!xyz%abc@example.com and _somename@example.com are not considered as valid.

[42wim]

If made a PR here : https://gitea.com/go-chi/binding/pulls/12 which uses the stdlib net/mail (which is rfc5322 compliant) for validation

[lunny]

That function allow utf8 chars which was Gitea dropped.

[42wim]

Ok, closed PR

[zeripath]

This was my worry when the email character restrictions were merged. There is really only one thing we should not be allowing outside of RFC5322:

• An initial -

but even that is really not our responsibility - it's only a problem with those running sendmail commands and the way they've configured the command. It should probably be an optional setting.

I think that UTF-8 should be allowed - at least optionally - we're no longer in the 80s and whilst the majority of email addresses are still using only basic ASCII it's not really right to still be restricting in this matter. If there are issues with ambiguous characters (and there would be) we can fix the display of those (and in fact #19990 would provide the mechanism for doing this.)

[oott123]

How about user@some-domain.com? Dashes in domain names is very common.

[theAkito]

Many websites get this one wrong, because web developers are too lazy. _@mail.com is a perfectly valid e-mail address.

[zeripath]

This feels like something that is going to go round and round in circles.

The restriction is in:

gitea/models/user/email_address.go

Lines 145 to 168 in 0e46499

	var emailRegexp = regexp.MustCompile("^[a-zA-Z0-9.!#$%&'*+-/=?^_`{|}~]*@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$")
	// ValidateEmail check if email is a allowed address
	func ValidateEmail(email string) error {
	if len(email) == 0 {
	return nil
	}
	if !emailRegexp.MatchString(email) {
	return ErrEmailCharIsNotSupported{email}
	}
	if email[0] == '-' {
	return ErrEmailInvalid{email}
	}
	if _, err := mail.ParseAddress(email); err != nil {
	return ErrEmailInvalid{email}
	}
	// TODO: add an email allow/block list
	return nil
	}

If you want to change/relax this you will need to make a PR that changes the code here.

You will also need to consider:

1. Sendmail - email addresses are sent as arguments to the command line - AFAIU disallowing an initial - should be all that needs.
2. Any other mail system - could arbitrary unicode characters break things?
3. Do we need to add ambiguous checking to the display of email addresses.

Code speaks louder than words. Make the PR.