Re: [Exim] weird From: line with diacritics

Quoth Philip Hazel on Thu, Apr 20, 2000:
> Did you have print_topbitchars set on when you posted this message? The
> copy I received had the character with hex code C8.

He probably did, but I set my xterm to display iso8859-1 (a.k.a.
Latin-1, a.k.a. Westerm European) charset. So, instead of
capital C with hacek (C\*v troff -ms notation) I got capital E
with grave accent (E\*` troff -ms notation). And I'm pretty sure
most of the people on the mailing list (well, at least those who
have a UNIX box on their desktop), including Philip, saw exactly
the same character.

> My personal view is that the 127-character restriction is ludicrious in
> this day and age.

Unfortunately, even if this restriction is removed, several
problems will still remain. If you want to write text in charset
different from default (iso8859-1?), for example, iso8859-2
(Eastern), koi8-r (Cyrillic) or iso8859-8 (Hebrew), you will
still have to indicate the charset, as was showed by this
message. If you want to transfer binary data, you will still
have to encode it somehow, because e-mail is line-oriented.

> On Thu, 20 Apr 2000, Petr Èech wrote:
> > 1) when it's not set, then the name with >127 chars gets mangled
> > 2) when it is set, than it sends the From: line unescaped. The To: line
> > gets escaped with mutt as "=?iso-8859-2?Q?Petr_=C8ech?=".

Here, mutt conforms to the standards.

> Why isn't mutt setting up the From: line then? Exim creates one only if
> there is a missing one. I didn't expect this to be common - it really is
> the MUA's job to create the message's header.

Apparently, authors of mutt don't think so for some reason.

> > The work-around is to set custom From: header, but then again exim adds
> > the Sender: header with (again) unescaped "Petr \v Cech".
>
> Run Exim 3.14. Set no_local_from_check. You will then get no Sender:

This is not a solution.

Vadik.

--
Do not meddle in the affairs of troff, for it is subtle and quick
to anger.