Owen O' Shaughnessy wrote: > My customer receives daily mailings from an advisor, but receives > corrupted characters in the message. > > The character set being used is iso-8859-1 > > When the message is received by courier it is sent using content > transfer encoding "7 bit". > When the message is received by a Microsoft exchange server, it is > sent using content transfer encoding "quoted-printable"
Well, a client may decide the transfer encoding upon connection. If the server advertises 8BITMIME on the EHLO answer, the client can use 8bit, otherwise it must do quoted-printable or whatever, if the message cannot be sent in plain 7bit (the default encoding). > The difference is certain characters in the character set are rendered > differently in the same MUA, an example would be the dash - character, > what is in the courier message source for this is: > =E2=80=93 > and what is in the exchange server message source is: > – The content-type header is also relevant. For text/html one can use character references, like –, as an alternative to quoted-printable. That way, the character U+2013 can also be written as –. However, it does not have an equivalent iso-8859-1 point, thus it cannot be encoded using quoted-printable in html text. E28093 is the UTF-8 encoding for that unicode point. Since content transfer encoding is done on top of any html encoding, the resulting document would be an illegal html text, if its encoding were quoted-printable, and its content-type header mentioned the utf-8 charset, and the html were tagged as iso-8859-1 (a rather unusual circumstance anyway.) > The message received through exchange renders a dash, whilst the > message received through courier receives something looking like a > with a hat symbol above it, a euro symbol, and a quotes symbol. That is the iso-8859-1 interpretation of those three characters; recall iso-8859-1 has a single byte encoding. Rendering as you report implies the content-transfer-encoding is quoted-printable, because if it were 7bit, the =E2=80=93 sequence would stand for itself just like it does here. > The only difference in the two mails is that the exchange server has > negotiated (?) "quoted-printable" content transfer encoding while the > courier server has used "7 bit". ESMTP does not provide for other negotiations, besides the server extensions declared in the EHLO response. It is the client who encodes the message, although servers may alter the content transfer encoding on the fly. > What determines the content transfer encoding? And is this problem due > to courier not supporting a better transfer encoding and having to > negotiate a lesser encoding scheme which corrupts characters in the > message? or is this down to something in the sending application? The server does not have to support MIME encodings. MIME has been designed to be compatible with unaware servers, and even pass through some unaware gateways. The sender application probably sends illegal content anyway. If it is a Microsoft application, chances are that it relays on some non-standard feature of Exchange servers, according to a company-private protocol concept that has been poisoning the net for decades. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
