[RavSinghChandan]

With allow_domain_literal=True, me@[IPv6:::1] is accepted but me@[ipv6:::1] and me@[IPV6:::1] are rejected with "The part after the @-sign contains an invalid address literal tag in brackets."

RFC 5321 4.1.3 defines the tag with the ABNF literal "IPv6:", and ABNF literal strings are case-insensitive (RFC 5234 2.3), so all three forms are valid. The tag is now matched case-insensitively, and the normalized domain keeps the [IPv6:...] spelling, so all three normalize to me@[IPv6:::1]

[JoshData]

How did you come across this bug?

[RavSinghChandan]

I was reading through how domain literals are validated and checking it against the RFC 5321 grammar. The "IPv6:" tag is written as an ABNF string literal there, and those are case-insensitive per RFC 5234, so "ipv6:" should be accepted too. I haven't seen it fail for a real address, so I understand if you'd rather keep it strict. Happy to close it in that case.

[JoshData]

But why were you doing that and how did you come to check the RFC against this library? (I'm trying to understand why I'm getting so many PRs lately.)

I will merge the PR.

[RavSinghChandan]

Fair question. I use email-validator through pydantic's EmailStr in one of my FastAPI projects. Lately I've been going through the libraries in my stack with an AI coding assistant, checking edge cases against the specs they implement. I check each one myself and write the test before opening anything. I expect that's part of the wave you're seeing, so I'll keep it to things that are clearly real and not flood you. Thanks for merging.

[JoshData]

Thanks! I want the library to be correct but also have to make sure I'm using my time well.