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

Filtering invalid email addresses #564

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

maxempoint
Copy link

Possible Fix for #515 and a test case for handling invalid email addresses.

I added a small function which checks if the email addresses that are returned by the email parser are valid. If not they are note appended in the address list.

Additionally, I added a test case with a new test mail including the incorrect mail address mentioned in the issue #515 .

@@ -296,6 +296,11 @@ def test_html_only_mail(self):
self.assertIn(" ( https://", mail.body)
self.assertIn("*peter.mueller@kreis-steinfurt.de*", mail.body)

def test_invalid_mail_address(self):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally this should be more a unit test (and less like a integration test): parsing a whole email just to test parsing of addresses makes this test not very specific. Also adding a large email with an image attachment (?!) is too much.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the feedback! I agree this is to unspecific. I will remove this test and do it more like this (without parsing a whole email):

Suggested change
def test_invalid_mail_address(self):
def test_invalid_mail_address(self):
values = ["To: 'John Doe [#123]' <john.doe@example.com>"]
ret = get_address_list(values)
self.assertEqual('john.doe@example.com', ret[0].email)

@@ -269,11 +269,21 @@ def try_decoding(encoded, encoding=None):
return decoded


def check_mail(email: str):
# Credit for regex to Anđela Niketić at https://stackabuse.com/python-validate-email-address-with-regular-expressions-regex/
regex_mail = r"([-!#-'*+/-9=?A-Z^-~]+(\.[-!#-'*+/-9=?A-Z^-~]+)*|\"([]!#-[^-~ \t]|(\\[\t -~]))+\")@([-!#-'*+/-9=?A-Z^-~]+(\.[-!#-'*+/-9=?A-Z^-~]+)*|\[[\t -Z^-~]*])"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This regex is too complex to maintain for my taste (and still doesn't capture the complexity of proper email address parsing if you wanted to go there).
Please use the Django email validator instead.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you also for this feedback! I used the Django Email validator as you suggested. I recognized that it also catched two cases were the emails in the test data were invalid (according to the django validator):

  • In foirequest/tests/testdata/test_mail_05.txt on line 33: "CC: <Kämmerer.a@zdf.de>, Biogiani.D@zdf.de". The test test_recipient_parsing fails if the django email validator is used, because the first email-address is filtered. This seems so be a general problem with addresses which have umlaut characters in the local part. From what I found the django EmailValidator does not support non-ASCII characters in the local part. The email-validator for example has an allow_smtputf8 option which seems to be not available in the django validator.
  • In foirequest/tests/testdata/test_mail_08.txt on line 2: "X-Original-To: <fragdenstaat class="de"></fragdenstaat>".

I could additionally change the mail addresses in those two cases in the test data if this makes sense? And would it make sense to use another validator because of the umlaut problem?

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

Successfully merging this pull request may close these issues.

None yet

2 participants