Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revert changes for domains without MX #288

Open
gjuric opened this issue Feb 22, 2021 · 2 comments
Open

Revert changes for domains without MX #288

gjuric opened this issue Feb 22, 2021 · 2 comments

Comments

@gjuric
Copy link

gjuric commented Feb 22, 2021

I would kindly ask you to rethink your stance on the DNS validation regarding domains with missing MX records. I am talking about the change proposed here #258 and implemented in c4f7036

This library is pretty popular (over 130 million installs) and is a dependency of symfony/mailer. Making it "user friendly" by proclaiming valid email addresses as invalid is not doing a service to anybody. If one wants to block these domains as well there could/should be an option for that (and drop the previous warning).

There are a lot of not ideally configure domains in the world and not accepting emails from these domains looks like is not the best approach in my opinion.

@egulias
Copy link
Owner

egulias commented Feb 28, 2021

Hello @gjuric , thanks for sharing your thoughts.
As far as I know, Symfony uses the NoRFCWarning validation, which checks syntaxis and fails on any warning. They do not use DNSCheckValidation by default, which is good since it requires an outside network connection to do so and it slow and adds another dependency.
I understand that there might be a lot of wrongly configured domains , however at the same time making the owners understand they have to fix it will make a better internet (and life easier) for all of us.

@gjuric
Copy link
Author

gjuric commented Mar 1, 2021

Fair points, the problem is that the owners don't need to fix it since it is is valid per the relevant RFCs.

It is not valid just for this library. If somebody wants to block those as well that is his right, but I think making this an option would be a more sensible approach. Whatever you decide feel free to close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants