python-email-validator
python-email-validator copied to clipboard
validate_email should not check special use domains if check_deliverability is set to false
The reason why these domains are checked is for deliverability reasons. They are not forbidden from being used in (for example local) email addresses, and do not syntactically invalidate the address. I.e. as far as I can tell, simply this check should be part of the if globally_deliverable check.
The README documents that this can be changed by the caller by removing "local" from the special use domains list at runtime. Would that work? (My main goal is to give good, maximally safe defaults for the main use case. Allowing @local by default doesn't seem like a safe choice. And the globally deliverable option is really an undocumented hack of last resort.)
Not really in my eyes. While it is my special use case, it does not address the problem in general. The only reason special domains are checked as far as I can tell is to ensure global deliverability, so if there is a flag to toggle global deliverability checking, it should actually toggle checking of those special use domains.
I think what you're saying is that the library's options allow you to do what you want (through a combination of calling SPECIAL_USE_DOMAIN_NAMES.remove("local") and setting globally_deliverable to False), but you don't think the options are well designed. Did I understand right?
I am saying that my specific "test case" is a .local domain, but that the problem applies to the general handling of all special use domains as a class of tests.
So you can call SPECIAL_USE_DOMAIN_NAMES.clear() then.
Sure, everyone who just wants to syntactically validate and normalize email addresses could do that ... or the properties of the validation method could do what they claim to do.
I must say I don't see why this is such a contentious topic. Special use domain checking only makes sense in the context of global deliverability, so if the option is switched off, special use domains should not be validated.
It's not contentious. You just want the library to have a different design than what's documented in the README. Thanks for your input. I'll consider it when I have time to work more on this project.