karolyi
/
py3-validate-email
3
3
Fork 4
Code Issues 1 Pull Requests Projects Releases Wiki Activity

[BUG] AttributeError after the validation returns False for a valid email #99

New Issue
Closed
opened 2022-10-27 11:19:37 +02:00 by Ghost · 7 comments
Ghost commented 2022-10-27 11:19:37 +02:00
Copy Link
  • I have read and understood the FAQ

Describe the bug

The function returns False, but an AttributeError (calling startswith() method on None) raises from a different thread. The email inputted is valid.

To Reproduce

import logging
import sys

logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
from validate_email import validate_email
is_valid = validate_email(
    email_address='valid@email.com',
    smtp_debug=True
)
print(is_valid)

My debug output

image

Expected behavior

Return True, no errors

Please complete the following information:
image

  • Home network, dynamic IP
  • py3-validate-email==1.0.7

Additional context

None

<!-- Please don't delete this template or we'll close your issue --> - [x] I have read and understood the [FAQ](https://gitea.ksol.io/karolyi/py3-validate-email/src/branch/master/FAQ.md) **Describe the bug** The function returns False, but an AttributeError (calling startswith() method on None) raises from a different thread. The email inputted is valid. **To Reproduce** ```py import logging import sys logging.basicConfig(stream=sys.stderr, level=logging.DEBUG) from validate_email import validate_email is_valid = validate_email( email_address='valid@email.com', smtp_debug=True ) print(is_valid) ``` **My debug output** ![image](/attachments/68a9b136-5494-4ec9-8242-5e41c3246396) **Expected behavior** Return True, no errors **Please complete the following information:** ![image](/attachments/919f7255-252c-4d46-a19e-e9b47dafa91a) - Home network, dynamic IP - py3-validate-email==1.0.7 **Additional context** None
image.png
205 KiB
image.png
12 KiB
karolyi commented 2022-10-27 11:29:37 +02:00
Owner
Copy Link

To me it seems this is an error that doesn't stem from the module itself, but your domain name resolution seems not to be functioning properly.

Are you able to reproduce the bug every time you run your script?

I see you're on windows, can you provide the output of the following:

  • run nslookup
  • enter set type=mx
  • enter gmail.com
To me it seems this is an error that doesn't stem from the module itself, but your domain name resolution seems not to be functioning properly. Are you able to reproduce the bug every time you run your script? I see you're on windows, can you provide the output of the following: - run `nslookup` - enter `set type=mx` - enter `gmail.com`
karolyi commented 2022-10-27 11:41:01 +02:00
Owner
Copy Link

Until I'm unable to reproduce the bug at my side, I'm unable to fix it.

Problem is, I see no traceback going back to my module, so I can only guess which part can be causing this. But, I suspect that the dnspython and windows constellation is at fault here.

Can you please run the following in python, and tell its output:

import logging, sys
from dns.resolver import resolve
from validate_email.dns_check import dns_check
from validate_email.email_address import EmailAddress
logging.basicConfig(stream=sys.stderr, level=logging.DEBUG)
addr = EmailAddress('xxx@gmail.com')
dns_check(addr)
Until I'm unable to reproduce the bug at my side, I'm unable to fix it. Problem is, I see no traceback going back to my module, so I can only guess which part can be causing this. But, I suspect that the dnspython and windows constellation is at fault here. Can you please run the following in python, and tell its output: ```python import logging, sys from dns.resolver import resolve from validate_email.dns_check import dns_check from validate_email.email_address import EmailAddress logging.basicConfig(stream=sys.stderr, level=logging.DEBUG) addr = EmailAddress('xxx@gmail.com') dns_check(addr) ```
karolyi commented 2022-10-27 12:09:00 +02:00
Owner
Copy Link

I am not familiar with win23util.py (don't use python on windows much), but to me it seems that get_default_resolver() returns something windows specific, and there is a bug in there.

You could report this to dnspython. Also, make sure you test this with the most recent dnspython version, as they might already have figured this bug out and have a fix in place for it.

Feel free to come back to me with any information on this, however, please consider closing this bug for now as it's unrelated to this module.

I am not familiar with win23util.py (don't use python on windows much), but to me it seems that `get_default_resolver()` returns something windows specific, and there is a bug in there. You could report this to dnspython. Also, make sure you test this with the most recent dnspython version, as they might already have figured this bug out and have a fix in place for it. Feel free to come back to me with any information on this, however, please consider closing this bug for now as it's unrelated to this module.
Ghost closed this issue 2022-10-27 12:32:43 +02:00
karolyi commented 2022-10-27 12:34:45 +02:00
Owner
Copy Link

For further exploring this issue, do you use the latest python3.9 on windows?

If that's a bug in there (or a constellation between dnspython==latest and python3.9 on windows), it's still worth a bugreport for dnspython, as they might have a case to fix then.

Keep me updated.

For further exploring this issue, do you use the latest python3.9 on windows? If that's a bug in there (or a constellation between dnspython==latest and python3.9 on windows), it's still worth a bugreport for dnspython, as they might have a case to fix then. Keep me updated.
karolyi commented 2022-10-28 11:52:06 +02:00
Owner
Copy Link

Did you also try with 3.9.15?

Did you also try with 3.9.15?
karolyi commented 2022-10-29 11:17:31 +02:00
Owner
Copy Link

Too bad they don't provide installers for 3.9 anymore. This might well be a bug in python standard libraries, which they would have to fix.

It makes the situation easier/more acceptable that it works in newer versions.

Too bad they don't provide installers for 3.9 anymore. This might well be a bug in python standard libraries, which they would have to fix. It makes the situation easier/more acceptable that it works in newer versions.
karolyi commented 2022-10-29 12:17:39 +02:00
Owner
Copy Link

What you could also do is overwrite the standard libraries in your installation from the newest tarball and see if it still errors out.

Just an idea.

What you could also do is overwrite the standard libraries in your installation from the newest tarball and see if it still errors out. Just an idea.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
master
pypi-faggotry
v1.0.11
v1.0.10
v1.0.9
Labels
Clear labels   
bug

Something isn't working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
stale

   
wontfix

This will not be worked on

No Label
bug
duplicate
enhancement
good first issue
help wanted
invalid
question
stale
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: karolyi/py3-validate-email#99
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?