This is based on #81074 (comment):

we should probably be raising an error if the rendering policy does not have utf8=True and we don't have an "original source line" from parsing a message (which is the case here), rather than using the incorrect RFC2047 encoding.

Checking part.token_type == 'addr-spec' seemed like the simplest approach.

An alternative would be to introduce a new NonASCIIDomainLiteralDefect paralleling NonASCIILocalPartDefect and apply it in _header_value_parser.get_domain_literal(). And add NonASCIIAddrSpecDefect as a superclass of both. Then change _refold_parse_tree() to check any(isinstance(d, NonASCIIAddrSpecDefect) for d in part.all_defects) (and perhaps move it up with the other UnicodeEncodeError logic). (If we go this direction, PR #122477 will also need an update.)

Also, I think charset == 'unknown-8bit' is only possible in _refold_parse_tree() when the non-ASCII characters resulted from parsing an existing message: see the UndecodableBytesDefect logic just above the new code. (The added tests seem to confirm this.)

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be poked with soft cushions!

I have made the requested changes; please review again

Thanks for making the requested changes!

@bitdancer: please review the changes made to this pull request.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Looking at the code more closely, it is supposed to already be handing this case. The fact that it isn't indicates there's a bug there, and there were certainly missing tests. I will poke at this.

I've crafted a more complete fix for the bug. If you could review it, @medmunds, that would be great.

Since I switched to using the existing HeaderWriteError, I'm wondering if we need the versionchanged at all at this point, if anyone has input on that.

Documentation build overview

📚 cpython-previews | 🛠️ Build #32489666 | 📁 Comparing 37f13db against main (76b3923)

  🔍 Preview build  

Since this is a bug fix that isn't going to get backported because of backward compatibility concerns, we'll keep the versionchanged. We can always delete it if someone objects.

It occurs to me that if it is worth a versionchanged there should also be a What's New entry. Do you want to write one?

It occurs to me that if it is worth a versionchanged there should also be a What's New entry. Do you want to write one?

Something like this? [edited]

Index: Doc/whatsnew/3.15.rst
<+>UTF-8
===================================================================
diff --git a/Doc/whatsnew/3.15.rst b/Doc/whatsnew/3.15.rst
--- a/Doc/whatsnew/3.15.rst	(revision 71636d347e37db41a11a21419137fd7eb3423f74)
+++ b/Doc/whatsnew/3.15.rst	(date 1777572899407)
@@ -914,6 +914,16 @@
   (Contributed by Eric Froemling in :gh:`149085`.)
 
 
+email
+-----
+
+* Email generators now raise an error when an :class:`.EmailMessage` cannot be
+  accurately flattened due to a non-ASCII email address (mailbox) in an address
+  header. :attr:`.EmailPolicy.utf8` offers options for supporting Email Address
+  Internationalization (EAI).
+  (Contributed by R David Murray and Mike Edmunds in :gh:`122540`.)
+
+
 functools
 ---------
 

[Edited: trying to capture the attention of users who might be affected and direct them to the docs that have complete details.]

Yeah, that looks good. Though I'd say "The documentation for...offers" just to make it clear that it isn't the policy option itself that provides the support.

Although I guess technically it does...maybe your wording is correct.