You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
validate_email should not check special use domains if check_deliverability is set to false #122
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.
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.
Activity
JoshData commentedon Dec 13, 2023
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
@localby default doesn't seem like a safe choice. And the globally deliverable option is really an undocumented hack of last resort.)immanuel-h commentedon Dec 13, 2023
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.
JoshData commentedon Dec 13, 2023
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 settingglobally_deliverableto False), but you don't think the options are well designed. Did I understand right?immanuel-h commentedon Dec 14, 2023
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.
JoshData commentedon Dec 14, 2023
So you can call
SPECIAL_USE_DOMAIN_NAMES.clear()then.immanuel-h commentedon Dec 14, 2023
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.
JoshData commentedon Dec 14, 2023
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.