Doesn't strict=True make this is a backwards-incompatible change?

Do you mind to elaborate? It's a keyword-only parameter. It sounds very unlikely that someone calls this function with strict=True since the parameter doesn't exist anymore. I don't see the addition of this parameter as a backward incompatible change.

The incompatible change is obviously the fact the emails accepted previously are now rejected.

The incompatible change is obviously the fact the emails accepted previously are now rejected.

Yes.
If the default stayed strict=False, or to only warn by default on invalid addresses (for 2 releases), this would match the process in PEP 387. With strict=True, it seems that you'll need a SC exception for backwards incompatible behaviour -- and that can take time.

Or do you consider this a plain bug fix? In that case, why preserve the old behaviour?

This change falls into the "unfortunately interesting" category of being unsure we're doing everything correctly so it provides an opt-out. If we have confidence in our change and test suite of valid and invalid email address coverage we could proceed without the behavior flag.

Do we have such confidence?

I have 0% confience that this change make the parser fully compatible with all RFC. I have 100% confidence that this change rejects email addresses which were accepted before.

Sorry, as I wrote before, the whole parser should be rewritten from scratch to use grammar suggested by RFC, rather than the current design.

This change only make the situation "less bad".

Also it's common that when Python becomes stricter, someone comes and explain their valid use case relying on the old behaviour.

If it is backported, it should be 3.12.1.

Right, the version number should be updated in each backport. I removed the "needs backport" label to avoid automated backports.

Alpha versions do not exist for common user, so I would use the 3.12.x version in which the fix will occur in the main branch too. It will help users that drop support of 3.11.

I agree with the concept but that depends on the backport situation. It is fair to start with 3.13 here and if we do decide to backport it further as a security fix later on, the docs can be updated to say 3.12.x.

It can use regular expressions:

for m in re.finditer(r'(?s)\\?.', addr):
    yield (m.begin(), m.group())

Perhaps functions that use _iter_escaped_chars() can also be written using efficient regular expressions to avoid handling ever char separately. For example, _strip_quoted_realnames() could use r'(?s)(?:\\.|[^"])*|(")' or something like.

But do what looks good to you, I can optimize it later.

Perhaps functions that use _iter_escaped_chars() can also be written using efficient regular expressions to avoid handling ever char separately.

This PR is based on PR #108250 which uses the following code to strip quoted real names:

    # When a comma is used in the Real Name part it is not a deliminator
    # So strip those out before counting the commas
    pattern = r'"[^"]*,[^"]*"'
    ...
    for v in fieldvalues:
        v = re.sub(pattern, '', v)
        ...

But this regular expression doesn't handle escape quote character (\"). So I wrote _strip_quoted_realnames() to replace this invalid regex.

I'm not comfortable with regex to write a parser when the grammar is that complicated. For example, antislash can also be escaped: \\. I didn't check RFC carefully. I mostly tried to support escaped quote character (\").

Also, my priority here is more to get a fix as soon as possible, since the vulnerability was reported in March, and I have to fix the CVE at work as soon as possible.

Can there be escaped commas?

The parser doesn't support escaped commas:

>>> email.utils.getaddresses([r'Real\, name <[email protected]>'])
[('', 'Real\\'), ('name', '[email protected]')]

_pre_parse_validation and _post_parse_validation can use list comprehensions or be turned into generator functions.

_post_parse_validation() output should be a list. There is no advantage to convert it to a generator.

If _pre_parse_validation() becomes a generator, parseaddr() has to create a list anyway for list[0]. getaddresses() cannot use a generator for _pre_parse_validation() result neither, since it consumes fieldvalues twice.