Re: [exim] Iconv

Top Page
Delete this message
Reply to this message
Author: Ron McKeating
Date:  
To: Alan J. Flavell
CC: Exim-Users \(E-mail\)
Subject: Re: [exim] Iconv
On Fri, 2005-09-30 at 16:09 +0100, Alan J. Flavell wrote:
> On Fri, 30 Sep 2005, Ron McKeating wrote:
>
> [...]
> > 2005-09-30 00:29:23 1EL7q6-0000sg-Sw => >ÑîÏÈÉú <szyang8@???>
> > <adpgt@???> R=vacation T=address_reply
> >
> > What I want to know is if I recompile exim with the
> >
> > # HAVE_ICONV=yes option, will this convert the foreign
> > char set
> ^^^^^^^^
>
> Excuse a digression[1]
>
> > characters to the one in
> >
> > HEADERS_CHARSET="ISO-8859-1"
>
> Without any knowledge of the details, I can't imagine how this could
> work: the data that I'm seeing in your email are already being
> (mis)represented as iso-8859-1 - but presumably they were *meant* to
> be Chinese? Since there are no Chinese characters in iso-8859-1, I
> can't imagine how one could "convert" the original into that.
> Convert into unicode, maybe, and log as utf-8, perhaps, but are these
> characters legal in the context where we're seeing them? I suspect
> not.
>
> Do we even know what character encoding was intended in the original?
> There's no sign of it in that log entry. The only currently-
> acceptable way to include non-ASCII characters in headers, for
> example, would be using one of the defined MIME encodings, quoted
> printable or base64, including a statement of the character encoding
> that's in use. This doesn't seem to be happening here.
>
> hope this is vaguely useful.
>
> [1] In modern parlance this is better referred to as "character
> encoding". MIME was defined at a time when the distinction between
> character set, character encoding, etc. was less clear than it is
> nowadays.
>
>


OK this outgoing message occurs as part of a users vacation message, I
will investigate this I suspect it is the cause of the problem.

Thanks all

Ron

--
Ron McKeating
Senior IT Services Specialist
Computing Services
Loughborough University
01509 222329