Closed ryneeverett closed 4 years ago
I think that the email module's behaviour has changed since that ugly work-around was written, so good riddance. I'm surprised that our tests did not pick it up! Time for new tests?
This issue only exists if one has a text/plain mailcap entry (which apparently is commonly included in distributions). This comes down to the logic of the change I made in #1477. If there is no text/plain mailcap entry then the behavior does not change at all. If there is a text/plain mailcap entry, after #1477 the mail gets encoded and written to a temporary file where it is read by the mailcap program. This encoding step is where the bug lies.
As was pointed out in #1522, the mock I added on the plaintext test prevents this issue from emerging by emulating the behavior as if there were no text/plain entry.
Not sure if you noticed but this commit does add a test of utf8 with a text/plain entry.
Thanks for the explanation. And yes, I did not notice the test :) I'll push this as is. Cheers,
This seems to essentially revert 777823f414aab5dfa130174dc7c80cda8036d13f, the reasoning of which I don't yet follow.
This may resolve the issue in #1522.