Am 20.11.2013 03:04, schrieb Kaz Kylheku:
On 19.11.2013 07:29, A.L.E.C wrote:
On 11/19/2013 03:46 PM, Simon Loewenthal wrote:
CONTENT-TRANSFER-ENCODING: 7BIT CONTENT-TYPE: TEXT/PLAIN; CHARSET=UTF-8 with this CONTENT-TRANSFER-ENCODING: QUOTEABLE-PRINTABLE CONTENT-TYPE: TEXT/PLAIN; CHARSET=UTF-8 or this if its certain its only text CONTENT-TRANSFER-ENCODING: 7BIT CONTENT-TYPE: TEXT/PLAIN; CHARSET=ASCII
So, are you saying that a message can't be "described" as 7bit and charset=utf-8 even if it contains only ascii characters? Sounds like bullshit. Maybe it contains some non-printable/malformed chars but I don't see them in the provided sample.
"7 bit transfer encoding" with "charset UTF-8" is nonsensical, regardless of whether or not byte values > 0x7F actually occur in the data.
That is not correct. If a message is qp-encoded, UTF-8 and 7bit can make perfect sense. But even if the message is NOT qp-encoded and does NOT contain any hi-bit characters, UTF-8 is still a correct declaration.
Although not a "nice" and "least invasive" declaration, right. But still a correct one.
I would also prefer if Roundcube would first check if one of the following charsets would match in this order before blindly declaring UTF-8 (for Western Europe):
US-ASCII -> ISO-8859-1 -> ISO-8859-15 -> Windows-1252 -> UTF-8
But that doesn't mean that UTF-8 is wrong, if e.g. US-ASCII would match.
The receiving end is fairly justified in rejecting this and complaining loudly.
No, definitely not. See above.
Cheers,
Michael Heydekamp Co-Admin freexp.de Düsseldorf/Germany