RFC: is & valid in a domain?

[ben-manes]

Running a migration of and a user had registered with the domain pg&e.com. This passed my scrubbing using isValid(email) but failed during digestion due to json schema validator rejecting it. Switching to isValid(email, EmailAddressCriteria.DEFAULT) rejects the address as well. Skimming over the RFC I couldn't tell if this was allowed and why & was accepted.

[chconnor]

If you look here: https://tools.ietf.org/html/rfc5322#page-13 ... you'll see that the domain part of an email address is allowed "&" and all sorts of other stuff (the "atext" definition). That makes it a "valid" email address, even though it is not actually a valid domain and you can't deliver to it.

EmailAddressCriteria.DEFAULT disallows "ALLOW_DOMAIN_LITERALS", which is why it rejects as you expect, and apparently isValid() doesn't actually use DEFAULT by default.

@bbottema -- perhaps "DEFAULT" is a misnomer here, since the default of isValid() is actually RFC_COMPLIANT, or perhaps the default for isValid() should actually be changed to DEFAULT. :-)

https://github.com/bbottema/email-rfc2822-validator/blob/master/src/main/java/org/hazlewood/connor/bottema/emailaddress/EmailAddressValidator.java#L117

[bbottema]

Agreed, the naming is a little confusing. I will update this.

[bbottema]

Released in v1.1.0