On Thu, 20 Apr 2000, Petr Èech wrote:
> I've been looking for the cause of corupted From: line when sending mail from
> my computer running exim. Instead of "Petr \v Cech" (TeX notation) i get
> "Petr ?ech" which is ugly. I've trace this problem down to exim and
> specificaly exim.c:2553 - it corectly gets the name from /etc/passwd, but
> mangels it, unless print_topbitchars is set. That's a bug IMHO.
Unfortunately, RFC 822 specifically states that all characters in header
lines must be in ASCII, i.e. not have the top bit set. That is why Exim
does this by default. Setting print_topbitchars was provided so that
people who are happy to break the RFC rules can do so.
Did you have print_topbitchars set on when you posted this message? The
copy I received had the character with hex code C8.
My personal view is that the 127-character restriction is ludicrious in
this day and age. Sadly, it has not been removed in the revision of RFC
822 which is underway. After all, TCP/IP has always been an 8-bit
transport mechanism. That is why Exim is 8-bit clean as far as
transporting the data of a message goes. In fact, it won't touch
existing header lines; all it does is to ensure that any header lines *it
generates* conform to RFC 822.
> 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?=".
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.
> 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:
> Could this be, at least, somewhere documented? There are surely many people
> who have >127 in fullnames in passwd.
Noted. It currently says, in section 46.14, "In all cases the user name
is made to conform to RFC822 by quoting all or parts of it if
necessary." I will add what it does to top-bit characters.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
