Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept this contribution by verifying everyone involved has signed the PSF contributor agreement (CLA).

CLA Missing

Our records indicate the following people have not signed the CLA:

@flokli

For legal reasons we need all the people listed to sign the CLA before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You can check yourself to see if the CLA has been received.

Thanks again for the contribution, we look forward to reviewing it!

Two cents from me: if I was using this API I'd not want to it to modify the data being imported silently and in a lossy way so an exception raised (the current behavior) seems superior to me. Even better would be to actually accept non-ascii characters as-is but I'm not sure how feasible that is.

This was already silently skipping non-ascii things on lines that didn't start with a From - this PR just makes it consistent with the behaviour there. Also see https://bugs.python.org/issue42433#msg382169 why this is even considered a bug for earlier versions.

I'm totally unconvinced by https://bugs.python.org/issue42433#msg382169, but

This was already silently skipping non-ascii things on lines that didn't start with a From

seems like an argument to me, fair enough.

This PR is stale because it has been open for 30 days with no activity.

This isn't stale, but waiting for maintainer feedback (@bitdancer ?)

This PR is stale because it has been open for 30 days with no activity.

Still waiting for feedback from maintainers.

CLA signed

@CoolCat467 is there anything preventing this PR from getting merged? Anything needed to do on my side?

I think it needs maintainer review yet... Maybe look into adding reviewers in bpo?

I can't assign people in bpo, but I can cc @maxking and @bitdancer on this PR due to #17620.

Hi. I am having the same problem, I want to parse mbox files that contain international email addresses in the From field.
After some research I ended up here, and I would like to share my opinion.

I think that the premise of using .decode('ascii') is wrong, since email addresses can contain non-ASCII characters. In other words, expecting the text after From to always be ASCII and throwing an error, or just ignoring the other characters as in the case of this PR is not the proper behavior.

The way this library currently throws the UnicodeDecodeError makes it difficult to properly handle or skip an offending message while iterating over messages in a mailbox. This needs to be fixed.

This PR is stale because it has been open for 30 days with no activity.

Again just waiting for a review, not stale

Needs a news item and a test, but the fix itself looks fine.

I'd happily let someone else take this over to the finish line.