Domain (hostname) validation as a separate API

[harrel56]

Please describe the feature that you are requesting
Hi, is there any chance you would consider adding an API for domain validation, similarly as you did for ipv4 and ipv6 addresses? This would be really useful, as right now I'm considering reusing your domain validation logic by appending hostname with e.g. test@ (not sure yet if this is a viable solution/workaround). Or maybe I'm mistaken and what you do inside email validation cannot be exactly considered a proper domain validation? To be precise: I'm not interested in DNS or anything involving information coming from external sources (disposable domain, etc.) - just structural validation. I'd appreciate your input on that.

Thanks for this great lib,
cheers!

[RohanNagar]

Hi @harrel56, thank you for this feature request! You are correct that the validation within JMail should be considered proper domain validation. Prepending test@ to the domains you want to validate would be a good workaround for now, but I would be in favor of exposing this as an API too. I'll have to do some refactoring in order to properly do this, but I will make a pass at it this week and see if we can get this feature in.

[harrel56]

I did some digging in what I would ideally need - and it looks way more complicated than I initially thought. This is even related to your other opened issue regarding support for IDNA2008. Turns out that I'd also need to validate domain name against IDNA2008 and not IDNA2003 - which is just a huge complication in Java world.

To be more clear I'll show you test cases that I'd like to validate against (just check for fields data and valid):

• https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/main/tests/draft2020-12/optional/format/hostname.json
• https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/main/tests/draft2020-12/optional/format/idn-hostname.json

There are some really specific rule checks in here - I don't really know if introducing such level of detail is in your interest. Or even if those apply to email validation as well.

But putting all things aside: even in the current state of JMail domain validation it would be appreciated to have a separate API just for it. I'd gladly replace my regex with such an API :)

[RohanNagar]

I think that maybe the checks that JMail does would already cover those use cases, as currently email addresses should pass whether the domain is ASCII or not. But it will be good to keep that in mind. Thanks for the test cases - that will be helpful in writing tests for this feature and can help identify if there are in fact any gaps in the current validation!

[RohanNagar]

I was looking more at the provided test cases and I see what you mean now. Some of those are validating the punycode format which isn't done in JMail today. If you just provided test@xn--al-0ea.com today it would be considered valid, but that is invalid according to the test cases. This could be interesting 😄

[harrel56]

Yeah, and just to be clear: decoding punycode is one thing (and simpler one), and checking some arbitrary rules from RFC is another thing.
If we decoded said string xn--al-0ea, it would give us a·l (so it's a valid punycode), but it fails because the decoded version is not valid according to RFC 5892 because of this: https://tools.ietf.org/html/rfc5892#appendix-A.3