Timeout on DNS resolution => KeyError

[GregoireDelannoy]

Hello,

After upgrading to the latest version, I noticed a surprising behavior in case of resolution timeout:

>>> res = email_validator.validate_email('greg@domain.fr', check_deliverability = True, timeout=0.0000001)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/omnibook/lib/python3.6/site-packages/email_validator/__init__.py", line 266, in validate_email
    ret.mx = deliverability_info["mx"]
KeyError: 'mx'

As the function validate_email_deliverability() can return a dict containing the only key unknown-deliverability, the calling function raise a KeyError.

In a comment, you suggest not wanting to raise Exceptions in case of a timeout. I think it would be better to do it, but I agree not to make it children of EmailNotValidError. What's your take on the best way to do it?

All the best, and thanks for the lib.

[JoshData]

Thanks for reporting this. I messed up when I made changes in the latest version. I am going to push a fix right now and publish a new version later today or tomorrow if the fix looks good.

I think my original intention was to hide timeout errors. The rationale is that it's unclear if a timeout is a local problem or a problem with the email's domain name --- though I'm not sure if that's true. So the fix will go back to hiding the error. The effect will be that the mx and mx_fallback_type attributes on the object returned from validate_email will be None.

[JoshData]

When I push the fix this issue will close, but feel free to keep commenting here if there's a problem with the fix.

[GregoireDelannoy]

Sounds good, and fits our workflow: as we prefer a stricter check, we're already raising exceptions if the MX field is empty or has used a fallback.

It would be great to mention it in the doc, so that people don't get surprised if the mx is empty, they now to try a dig on their machine.

[JoshData]

I did update the README, but if it could be clearer, let me know.

[GregoireDelannoy]

Seems clear enough to me, as you mention it very close to the description of the mx field.

Many thanks for the quick fix :)