Use "non-strict" parsing for email.utils.getaddresses

[petschki]

fixes #4020

[mister-roboto]

@petschki thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[petschki]

@jenkins-plone-org please run jobs

[mauritsvanrees]

It sounds a bit weird: the test expects that "email\nemail" fails, which it does not, and you fix it by being less strict. I don't quite follow the logic, but I see locally that this fixes a test failure, also on Python 3.10.

[mauritsvanrees]

Can be merged when green.

[petschki]

in our case strict=False means "old parsing behavior" ... what I don't really understand is the new parsing behavior that when you do getaddresses(["[email protected]\[email protected]"]) you get [("", "")] back:

>>> email.utils.getaddresses(["[email protected]\[email protected]"])
[('', '')]
>>> email.utils.getaddresses(["[email protected]\[email protected]"], strict=False)
[('', '[email protected]'), ('', '[email protected]')]
>>>

[yurj]

python/cpython#102988 maybe this?

From the tests in the python email package (python/cpython@2a9273a), I think the problem is the use of '\n' in the Plone test.

[petschki]

Update: I think we should update the email validation to follow the actual strict behavior. So inputs like [email protected]\n [email protected] aren't valid anymore. But I found out, that if you separate mails only with a comma it returns the expected result:

python 3.11.10

>>> email.utils.getaddresses(["[email protected],\n [email protected]"])
[('', '[email protected]'), ('', '[email protected]')]
>>> email.utils.getaddresses(["[email protected]\n [email protected]"])
[('', '')]

python 3.11.5

>>> email.utils.getaddresses(["[email protected],\n [email protected]"])
[('', '[email protected]'), ('', '[email protected]')]
>>> email.utils.getaddresses(["[email protected]\n [email protected]"])
[('', '[email protected]'), ('', '[email protected]')]

So in addition to the len() I'd check for the fallback return value [('', '')] here https://github.com/plone/Products.CMFPlone/blob/master/Products/CMFPlone/PloneTool.py#L163
Checking for an empty address in validateSingleNormalizedEmailAddress() is the better idea because EMAIL_RE.sub("", "") is always empty (therefore True).

What do you think? -> see #4023

[mauritsvanrees]

What I still don't get is why these tests pass fine on Jenkins with the CMFPlone master branch, but locally they fail.
Ah, if you already get a difference between Python 3.11.10 and 3.11.15, then that may be the explanation. Locally I have all the latest bugfix releases installed, and Jenkins probably lags a bit behind.

Also, https://docs.python.org/3/library/email.utils.html says the "strict" parameter was introduced in 3.13. But the links you pointed to in issue #4020 already mention this in the release notes of 3.11 and 3.12. Ah, those are also notes for bug fix releases, they were not yet in the first final releases.

Meanwhile locally I see that even the latest Python 3.8 has the "strict" parameter.

So indeed the way to go is not to rely on getaddresses working properly, but to have our own extra checks.

[mauritsvanrees]

Closing this PR in favour of #4023