Fix utf8 encoding with a text/plain mailcap entry.

[ryneeverett]

This seems to essentially revert 777823f,
the reasoning of which I don't yet follow.

This may resolve the issue in #1522.

[pazz]

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?

[ryneeverett]

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.

[pazz]

Thanks for the explanation. And yes, I did not notice the test :)
I'll push this as is. Cheers,