Hello Dr. F.!

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.

Mr. Ritter should be geheilt.  That is a worldwide success, no?

 |First of all I had done/add some patches[0] for the old heilroom-mailx,
 |like my mime autodetection of the encoding of a piped message even within
 |a clean POSIX locale.  Also some extensions for options, mainly like
 |the -R option[1] and the handling of mail addresses before and afther
 |the options.

Ah!  This is the first i see.  A couple of years ago i was
searching around for packager patches, but could not find just
anything (but Debian, mostly).  If you do not know where to look,
you are lost.

So this is where this ends up..   Your usage of -R, that is
a pity.  We do support Reply-To: when parsing and such, your -R is
in effect "-S reply_to=arg".
Note our builtin getopt does not support optional arguments.
What can be done about this?

 |Also I'd like to ask how to enable the RFC4155 as default as I can
 |not break mbox out there.  This was the first what I've seen on my
 |various tests with my test mbox folders around here and I'd like to
 |avoid that users/customers have to edit their mbox based folders[2]

Well, i hope we do not break MBOXes!
The default parser uses the laxe POSIX standard rules for MBOX
parsing (Vol. 3, Shell and Utilities, mailx), and these specify
(in OUTPUT FILES) "line beginning with From space" ... "one or
more header lines" ... "empty line" ... "zero or more body lines,
followed by empty line".

Of course the standard just names the lowest common denominator of
the MBOX mess which started with UNIX v5 iirc.
The problem is old, there is MBOXO quoting etc., then there was
Content-Length: and such, which Zawinski had a humble opinion on
and off[1].
The standard RFC 4155 defines a stricter format which is harder to
get wrong, but i cannot enable this by default.
Also, the way we do it is not good.  We should properly MIME
reencode the entire message, in order not to mangle actual
content.

So what you actually mean is that i should peek one line in
advance and check whether a (required) header line follows?  This
is actually a very good idea, and will i see what i can do about
that!

  [1] https://www.jwz.org/doc/content-length.html

 |As last I'd like to ask how to fork and make e.g. pull requests
 |or is this done by using emails only with attached git patches?

We only have this ML (and s-announce@ with low traffic).  Patches,
of course, if you want to.  Oh yes, i cannot await seeing git
patch subjects!!  Note there is a _somewhat_ low message size
limit, i also use "format-patch --stdout|gzip" or zstd -19 or
whatever you want.

 |Werner
 |
 |[0] https://build.opensuse.org/package/show/server:mail/mailx

IPv6 addresses, would be nice.  I had a Net::IPAddress which could
do it, back and forth, one and half a decade ago.  Pffffh!
Maybe it would need some polishing, device stuff and such.

MIME detection.. great..  Well, the character set stuff we do
differently, automatic character set detection is quite
complicated stuff if done right[2,3].
This is immense, and clearly beyond the scope of the mailer itself.
Likely even beyond the scope of this c....y little Unicode support
library which i will hopefully manage to do one day.
So i thought the best we could do is to offer clear logical rules
and obey them.  The manual entry for -a and then "Character sets"
does this.
Yes, we do have special Unicode/UTF-8 paths in the software, when
the detected locale is Unicode/UTF-8 aware.  I do not think i will
add automatic checks for UTF-8 compatible byte sequences.
I personally am very frustrated of what the standards have to
offer, i think all this hard-wiring of byte values is a very bad
thing: even the ASCII control character byte checks everywhere.
But that is how it grew, i cannot help it.  If anyone invented
a character set which does not comply they are lost.

DTLS support for a MUA is very cool stuff!
S-nail uses the tls-config-pairs= variable, which is passed
through directly to SSL_CONF_cmd(3) if available.  We also do
support program specific OpenSSL configuration file modules.

  [2] http://userguide.icu-project.org/conversion/detection
  [3] https://github.com/google/compact_enc_det

 |[1]
 |     -R | -R address
 |            Without any argument any folders will be opened read-only.
 |            With argument an reply-to adress is specifed on command line.
 |            Only the first argument after the -R flag is used as the \
 |            address.

-R flag.  This now really works, btw.  We do not support optional
arguments, and Heirloom did not too.  This must be some other
getopt implementation that is used.  How many use cases are
there are SUSE which rely on this?  Can't you simply say "-S
reply_to=address"?  Hmm.  Eighteen years old is this patch.

 |[2]
 |--- /tmp/bad.mbox       2018-12-11 10:42:44.022544988 +0100
 |+++ /tmp/good.mbox      2018-12-11 10:42:44.718532118 +0100
 |@@ -180095,7 +180095,7 @@ which should reduce everyone's integrati
 | 
 |     https://github.com/neomutt/neomutt/issues/28
 | 
 |-From clean Mutt source, it shows which patches each distro uses and the
 |+>From clean Mutt source, it shows which patches each distro uses and the
 | Status: O
 | 
 | order in which I'd like to maintain them.
 |@@ -295051,7 +295051,7 @@ Hi Werner,
 | 
 |     over binaries not mention in texlive.tlpdb.xz
 | 
 |-From where did you get this texlive.tlpdb.xz? Those binaries are all
 |+>From where did you get this texlive.tlpdb.xz? Those binaries are all
 | Status: O
 | 
 | included in the texlive.tlpdb that's in the pretest directory, as far as
 |
 |
 |-- 
 |  "Having a smoking section in a restaurant is like having
 |          a peeing section in a swimming pool." -- Edward Burr
 --End of <20181213092255.ga12...@boole.suse.de>

--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)

Reply via email to