AddressHeader problem when FriendlyName is improperly quoted and contains comma

[fostervbv]

Bug report

Bug description:

Given an address text of the form: John Smith, Jr <johnsmith@example.com>
Because of the unquoted comma, the text is parsed as two addresses:
"John" <@smith>, "Jr" <johnsmith@example.com>
This is of greatest concern if the object is supposed to be a SingleAddressHeader.

I have also encountered TO and CC strings that have incomplete address specifications, containing only a Friendly Name. For these messages, I am only interested in the valid addresses, although others may want the existing behavior.

To work around both the parsing problem and the invalid address terms, I created a sub-class which discards any address where username or domain are not strings. My workaround does not correct for the incomplete Friendly Name, but it ensures a correct count of valid addresses. It would be desirable to implement a trap for unquoted commas, but there are so many challenges to parsing address lists correctly, I wonder if fixing the unquoted comma problem will create other headaches.

Problem observed on Python 3.11.3150.0 and Python 3.8.1

CPython versions tested on:

3.11

Operating systems tested on:

Windows

[picnixz]

Please show us a reprocible example. Is it the email module?

[fostervbv]

Yes, I am referring to the email module, and the AddressHeader object with its variants.

Second issue first:
I observed a long CC list which was apparently truncated by Outlook due to length. It ended with:
, "john doe"
The final term was parsed correctly as a DisplayName with no address. It is a philosophical question of "what do we want the software to do with an email address object that lacks an email address?" For my purposes, I want to discard it, but the addresses object is a tuple, not a list, so the only way to alter the result is to clone it into a list object. I don't have a specific recommendation for development, but wanted to document the issue that I observed.

The first problem is also caused by malformed content, but it is more common. Display Names are not required to be quoted, and often are not. But if a comma appears in the DisplayName, it should be quoted so that it is not treated as an address term delimiter. Unfortunately, this simple rule is often violated. The email module splits the list at the comma, then attempts to construct two address headers from the results. The result is one address object with no email address, and another address with a portion of the intended DisplayName text

As far as an example, I don't know what you need beyond the text that I provided. You should be able to drop it into any EML file as a From header or Reply-To header for testing. I don't have freedom to post an actual email message in a public forum.