Hello.
It took some time, i am sorry.
The second half of 2018 i did not spend that much time on the MUA,
and was mostly fiddling around with some utility stuff, which
hopefully will pay off later.
Dr. Werner Fink wrote in <20181217134450.ga9...@boole.suse.de>:
|On Thu, Dec 13, 2018 at 06:06:24PM +0100, Steffen Nurpmeso wrote:
|> Werner Fink wrote in <20181213092255.ga12...@boole.suse.de>:
|>|I'm new here as I've been informed that s-nail is the successor of
|>|heilroom-mailx. On the first tests I see some problems with s-nail.
...
|The autodetection of utf8 is simple and well defined in ISO/IEC 10646
|(also shon in utf8(7) manuala page section Encoding) and it helps a
|lot in pure POSIX locale:
...
| echo \303\266\303\244\303\274 | .obj/mailx -s test wer...@suse.de
| mailx: Cannot find a usable character set to encode message: No such \
| entry, file or directory
| /suse/werner/dead.letter 3/45
| mailx: ... message not sent
|
|it is a major feature for my users which uses mailx for system mails.
|As the patched mailx does also catch binary code with the correct
|
| echo ^A^B | mailx -s test wer...@suse.de
|
|where ^A and ^B are Ctrl-A (SOH) and Ctrl-B (STX) ... this is seen
|my mutt as this
...
Well, hm. The latter are 7-bit ASCII control characters which the
entire world is compatible with out of self-interest. This MUA
will treat them as such -- they are none of the special exceptions
(like HT tabulator, even BS backspace and BEL bell) --, and use
octet-stream with base64 encoding.
Whereas the former are bytes with the 8-bit set, which could be
just about anything. Since the examples have no other
peculiarities, we think this is text and try to adhere to the
*ttycharset* / *sendcharsets* / *charset-8bit* / *charset-7bit*
interpretation of text, and with compiled-in iconv(3) support we
fail badly.
So far as to repeat the situation (and not go into the detail of
locales and iconv, as you know all that).
Of course you are right. But... I cannot do that kind of auto-
detection, doing this right would be expensive and complicated
and never be a hundred percent, and all that on top of the current
situation of the software (it still uses STDIO, for example).
I feel the need for some context. For example musl iconv(3) seems
to be unable to convert a "hä" file with UTF-8 BOM to LATIN1.
This is an UTF-8 BOM with explicit UTF-8 input character set
selection. This MUA has to become better, for example we really
should be able to get UTF-16 right, too (and get rid of *mime-
allow-text-controls*, a terrible variable).
So what to do.
Today i have implemented yet another variable, *charset-
force-transport* (i really dislike the trailing part). I think
this matches your actual expectation of behaviour, and is what is
possibly desirable as such, but, of course: this variable must be
turned on explicitly:
#?0|essex:nail.git$ printf '\303\266\303\244\n' |
LC_ALL=C /tmp/y/s-nail -:/ -stest -Snosave -Sexpandaddr -
...
s-nail: ... message not sent
#?4|essex:nail.git$ printf '\303\266\303\244\n' |
LC_ALL=C /tmp/y/s-nail -:/ -stest -Snosave -Sexpandaddr \
-Scharset-force-transport -
From steffen Thu Jan 3 20:58:56 2019
Date: Thu, 03 Jan 2019 20:58:56 +0100
Subject: test
MIME-Version: 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
w7bDpAo=
#?0|essex:nail.git$
And i can read this message with my setting of
*mime-counter-evidence*=0b1111 without doing anything else.
I hope this is somehow satisfying!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
