[quote user="irelam"]
IMHO the type of text/plain should cause charset info etc to be ignored, which is what I think Outlook is doing.
[/quote]
There are two factors in play here: the first is the MIME content-type, "text/plain". This is a formal indicator that says the content is unadorned text organized on a line by line basis: it does not say anything about the nature of the text itself, although in the absence of any qualifier, it defaults to characters complying with the US-ASCII character mapping. The "text/plain" declaration on its own, though, merely indicates that the content is readable, unadorned text organized as terminated lines.
The second factor is the explict charset declaration, which indicates the character mapping of the content. It is important to understand that a charset declaration may inherently imply a particular bit
layout of the content - it might be 7-bit, 8-bit or even 16-bit
characters, depending on the character set specified (RFC2046 is quite
explicit about this). If the content contains data other than pure
ASCII, however, then it must usually be encoded using a transition
armouring, such as BASE64. The presence of such armouring is specified
by a separate header, Content-transfer-encoding. It is also very important in understanding what's happening here to realize that RFC2045/2046 specifically states that if the charset parameter is not recognized, then a compliant mailer should assume US-ASCII and render accordingly.
Now, what the headers from this message are saying is that the content of the body is plain text, using a specific Korean character layout. As it happens, Pegasus Mail uses an extremely poweful character conversion library called iconv which can handle a huge range of character mappings, and the particular Korean variant specified in the headers is one it knows. As a result, Pegasus Mail quite correctly assumes that the content is Korean and tries to present it accordingly. Outlook and the other mail programs, by contrast, quite possibly do NOT recognize this particular character set and, in compliance with the MIME specification, fall back to rendering in US-ASCII. Now, because the header is actually wrong (it doesn't match the actual content), this results in the default behaviour rendering the data correctly, while Pegasus Mail's more correct handling yields rubbish.
This is a long explanation, but the solution is simple - get the sender to fix his headers. I hope the detail serves to explain why you're seeing what you are, though.
Cheers!
-- David --
[quote user="irelam"]<p>IMHO the type of text/plain should cause charset info etc to be ignored, which is what I think Outlook is doing.</p><p>[/quote]
There are two factors in play here: the first is the MIME content-type, "text/plain". This is a formal indicator that says the content is unadorned text organized on a line by line basis: it does not say anything about the nature of the text itself, although in the absence of any qualifier, it defaults to characters complying with the US-ASCII character mapping. The "text/plain" declaration on its own, though, merely indicates that the content is readable, unadorned text organized as terminated lines.
The second factor is the explict charset declaration, which indicates the character mapping of the content. It is important to understand that a charset declaration may inherently imply a particular bit
layout of the content - it might be 7-bit, 8-bit or even 16-bit
characters, depending on the character set specified (RFC2046 is quite
explicit about this). If the content contains data other than pure
ASCII, however, then it must usually be encoded using a transition
armouring, such as BASE64. The presence of such armouring is specified
by a separate header, Content-transfer-encoding. It is also very important in understanding what's happening here to realize that RFC2045/2046 specifically states that if the charset parameter is not recognized, then a compliant mailer should assume US-ASCII and render accordingly.
Now, what the headers from this message are saying is that the content of the body is plain text, using a specific Korean character layout. As it happens, Pegasus Mail uses an extremely poweful character conversion library called iconv which can handle a huge range of character mappings, and the particular Korean variant specified in the headers is one it knows. As a result, Pegasus Mail quite correctly assumes that the content is Korean and tries to present it accordingly. Outlook and the other mail programs, by contrast, quite possibly do NOT recognize this particular character set and, in compliance with the MIME specification, fall back to rendering in US-ASCII. Now, because the header is actually wrong (it doesn't match the actual content), this results in the default behaviour rendering the data correctly, while Pegasus Mail's more correct handling yields rubbish.
This is a long explanation, but the solution is simple - get the sender to fix his headers. I hope the detail serves to explain why you're seeing what you are, though.
Cheers!
-- David --
</p>