On Thu, Dec 13, 2018 at 06:06:24PM +0100, Steffen Nurpmeso wrote: > 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?
Hello ... ohmm .. mea culpa, should be s/heilroom/heirloom/ > |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. Ah ... never seen a mail about s-mailx/s-nail. And as mailx seems to be not active maintained I had done a lot of patches to get my users and customers happy. The patches are grown with the bug reports ;) > 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? The problem was that this -R option is very old and Gunnar was faster with his next version with an own -R option. Therefore I had used the glibc feature of getopt(3) with its two colon which support an optional argument for an option. Simply not to break customers scripts using mailx out there. > > |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". What I see is There are new messages in the error message ring (denoted by ERROR) The `errors' command manages this message ring ERROR# ? for several mailboxes which contain mail body including a "From " at at the beginning of the line. AFAICS nnon of the do use a mail address nor a date after this initial "From " but a normal sentence :) > > 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 usage of the Content-Length: tag would be very perfect grep -E ^Content-Length ~/Mail/mailbox | wc -l 537 if available. AFAIK the sendmail as well as the postfix with procmail do use it (or you have to use -Y for `traditional Berkeley mailbox format'). Whereas mail.local(8) from sendmail and local(8) from postfix do use `traditional Berkeley mailbox format'. > 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. I'm aware of RFC4155 but it would be very fine not to get users in panic back on the bugzilla due this if procmail was in use. > 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. 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 öäü echo \303\266\303\244\303\274 | mailx -s test wer...@suse.de echo $? 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 Date: Mon, 17 Dec 2018 14:22:09 +0100 From wer...@suse.de Mon Dec 17 13:22:12 2018 From: "Dr. Werner Fink" <wer...@suse.de> To: wer...@suse.de Subject: test Return-Path: <wer...@suse.de> User-Agent: Heirloom mailx 12.5 7/5/10 [-- application/octet-stream is unsupported (use 'v' to view this part) --] > > 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 Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr
signature.asc
Description: PGP signature
