Depressing openpop mime parser

It seems that openpop is rarely used ...... So there are some things about openpop/opensmtp/mail. net ...... No response ......

However, I 'd like to know whether the source of inspiration for openpop development has not seen these messages or what is going on?

Well ...... Even more about openpop ...... However, I just want to talk about its mime parser ...... Convert an email from RFC 822 to an object class ......

It's really depressing ......

In its parse, encoding. Default is used in many places. Regardless of the specific email encoding, all of them use the encoding of the current system to parse ......

Because this parse can be correctly decoded in many cases, and the source code has the following annotations:
<Param name = "encode"> encoding method, "default" is suggested </param>

We recommend that you use the default system encoding ...... I really don't understand the secrets ......

Check the code of its parse email header ...... It seems that ...... There is also a small bug ......
Sometimes the charset information is followed by the Content-Type ...... In this case, Parser can correctly obtain the email code ......

However, sometimes charset is still behind Content-Type, but it will wrap and add a tag, such:
Content-Type: text/html;
Charset = "US-ASCII"

In this case, Parser seems to have ignored charset ......

Or, that's why the English letter in the parse UTF-8 Code went wrong ......

However, there is another serious problem: the quoted-printable function is wrong ......

Line 1 of decodeqp. CS contains the following content and comments:
If (isbegin & (count % 2 = 0) // wait until even items to handle all character sets

But for UTF-8 encoding, each character is three bytes ...... It seems that it should be changed:
If (isbegin & (count % 3 = 0) // wait until even items to handle all character sets including UTF-8

Otherwise, words are missing.

Alas ...... Depressing openpop mime parser ......