On 2/10/23 03:32, Carlos E. R. wrote:

Is it compatible? A replacement?

Meaning, same command line? That's an absolute need, there are many scripts and programs that use the ancient "mail" command line. Mailx is a direct replacement, no changes needed.

Yes, Same options, same -a attachment, etc... -- David C. Rankin, J.D.,P.E.

On 2/10/23 03:48, Dr. Werner Fink wrote:

Simply s-nail is not mailx aka Heirloom mailx/nail. I had tried s-nail and seen that I was not able to read my own mbox folders.

s-nail is a offshoot from BSD mail but is option compatible with hierloom mailx. Everything works with the current mailx, but the lack of development means that still uses the 2010 cryptography. There have been a number of updates, tls several times and most recently in glibc 2.37. Just something to look at. I don't have a problem reading mail on Arch with s-nail, so we can look at any additional patches. But the version v14.9.24, from 2022-03-26 likely obsoletes most of the patches you have. -- David C. Rankin, J.D.,P.E.

On 2/10/23 06:55, Dr. Werner Fink wrote:

On 2023/02/10 04:43:31 -0600, David C. Rankin wrote:

...

On 2/10/23 03:48, Dr. Werner Fink wrote:

...

Simply s-nail is not mailx aka Heirloom mailx/nail. I had tried s-nail and seen that I was not able to read my own mbox folders.

s-nail is a offshoot from BSD mail but is option compatible with hierloom mailx.

Everything works with the current mailx, but the lack of development means that still uses the 2010 cryptography. There have been a number of updates, tls several times and most recently in glibc 2.37.

Just something to look at. I don't have a problem reading mail on Arch with s-nail, so we can look at any additional patches. But the version v14.9.24, from 2022-03-26 likely obsoletes most of the patches you have.

Sow me how you set a Reply-To: entry within the command line or with an option at calling s-nail. Also does s-nail support autodetection of UTF-8 encoded attachments provided with the option -a at calling s-nail?

reply-to: is handled through user config files, e.g. ~/.s-nail.rc ## Mbox settings: set from='SDF User ' set reply-to='SDF User ' Attachments can apply character set changes if needed, but presume the attachment is in the default system locale character set which is UTF-8. -- David C. Rankin, J.D.,P.E.

On 2/11/23 04:08, Carlos E. R. wrote:

mailx:

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

That's a difference, then.

Yep, 13 year old mailx winds that round :) -- David C. Rankin, J.D.,P.E.

On 2/12/23 09:25, David Thorburn-Gundlach wrote:

Hi, all --

I've been watching this with some interest. Sometimes old doesn't mean bad; it's possible to accomplish a refined design and not need any further tweaking. Not that I'm going to go looking at the moment, but for example I think bc has been stable for almost as long as I've been using it :-)

David, While s-nail incorporates several rc files, I think the answer here is it wouldn't be as convenient as the -R option in heirloom-mailx. It would likely be simpler to write a procmail rule to do a header rewrite. That also brings up the point it would also likely be simpler just to patch s-nail with a new -R option to insert the given reply-to address. That's less than a dozen lines of code in C. Dr. Werner Fink's concern is valid for the -R option. Which is a difference in the options. When Arch looked at the issue of changing the command line mailer in the 2011-2012 timeframe, they went with s-nail because heirloom (and other flavors) of mailx were no longer actively being developed (that provides an upstream for fixes as things are discovered) Granted, this is needed a bit more with Arch that remains current with upstream for its model. SUSE/openSUSE has always tweaked and backported a bit more -- and has always had the resources to use that model. (and thank goodness for that given my "choice" of desktop) It would at least be nice to have the "choice" of s-nail as a supported package if not a replacement. I'll pull the source and see what it would take to add a -R option. -- David C. Rankin, J.D.,P.E.

On 2/14/23 06:31, Per Jessen wrote:

I haven't looked, but surely someone is already building it in a home repo? It wouldn't much to have it made "officially" available for TW.

Yes, but sans wep, the only way to search home is through buildservice :( -- David C. Rankin, J.D.,P.E.

On 2/15/23 02:58, David C. Rankin wrote:

On 2/14/23 06:31, Per Jessen wrote:

...

I haven't looked, but surely someone is already building it in a home repo?  It wouldn't much to have it made "officially" available for TW.

Yes, but sans wep, the only way to search home is through buildservice :(

Last build of s-nail was 9-years ago, nothing even remotely current. But, beyond that, somebody delete my drankatty build service project so I can't even build it myself now. How the hell did that happen? I've had that build service project since Novell owned openSUSE and I use it occasionally for builds such as this. Why was it deleted when in response to the request I requested it NOT be deleted!!! I need my drankinatty build service project restored ASAP. -- David C. Rankin, J.D.,P.E.

On 2023/02/13 19:36:03 -0600, David C. Rankin wrote:

On 2/12/23 09:25, David Thorburn-Gundlach wrote:

...

Hi, all --

I've been watching this with some interest. Sometimes old doesn't mean bad; it's possible to accomplish a refined design and not need any further tweaking. Not that I'm going to go looking at the moment, but for example I think bc has been stable for almost as long as I've been using it :-)

David,

While s-nail incorporates several rc files, I think the answer here is it wouldn't be as convenient as the -R option in heirloom-mailx. It would likely be simpler to write a procmail rule to do a header rewrite.

That also brings up the point it would also likely be simpler just to patch s-nail with a new -R option to insert the given reply-to address. That's less than a dozen lines of code in C.

Dr. Werner Fink's concern is valid for the -R option. Which is a difference in the options.

See thread followed on https://www.mail-archive.com/s-mailx@lists.sdaoden.eu/msg00808.html some changes had been done but currently s-nail is not compatible with old mailx. I'm in doubt that it every will be. Also I'd like to avoid to fork s-nail to port my patches on every new version of s-nail. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On 2023-02-10 17:03, Per Jessen wrote:

David C. Rankin wrote:

...

On 2/10/23 03:48, Dr. Werner Fink wrote:

...

Simply s-nail is not mailx aka Heirloom mailx/nail. I had tried s-nail and seen that I was not able to read my own mbox folders.

s-nail is a offshoot from BSD mail but is option compatible with hierloom mailx.

Everything works with the current mailx, but the lack of development means that still uses the 2010 cryptography.

Is that really a problem for a command-line tool? Just being curious.

For me, mailx is perfect for anything I want to do in batches, and occasionally when I want to send a mail without cranking up TB.

It _might_ have problems connecting to some mail servers out there. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

On 2023-02-11 09:30, Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-02-10 17:03, Per Jessen wrote:

...

David C. Rankin wrote:

...

On 2/10/23 03:48, Dr. Werner Fink wrote:

...

Simply s-nail is not mailx aka Heirloom mailx/nail. I had tried s-nail and seen that I was not able to read my own mbox folders.

s-nail is a offshoot from BSD mail but is option compatible with hierloom mailx.

Everything works with the current mailx, but the lack of development means that still uses the 2010 cryptography.

Is that really a problem for a command-line tool? Just being curious.

For me, mailx is perfect for anything I want to do in batches, and occasionally when I want to send a mail without cranking up TB.

It _might_ have problems connecting to some mail servers out there.

Ah, again way too advanced usage for me :-) I only drop mails into the MTA queue.

Anyway, to accommodate my simpleton needs and those of more advanced beings, surely we have room for both mailx and s-nail ? But of course, we had the same thing long ago, when we had both the ancient "mail" and the new "mailx". The problem is if it is done as a replacement: mailx could directly replace mail and the scripts continued running without modification. When the same command line was assured

Me too, but some people use it (in scripts, crons, etc) to send email talking directly to an ISP MTA. Remember that there was talk, years ago, of removing the MTA from the default installation. then the command was replaced. Of course, the new mail can have new options. But has to accept the same old ones, with same behaviour. So far, "-R address" is different. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)

Per Jessen wrote:

Carlos E. R. wrote:

...

On 2023-02-11 09:30, Per Jessen wrote:

...

Anyway, to accommodate my simpleton needs and those of more advanced beings, surely we have room for both mailx and s-nail ?

But of course

Good, end of thread me thinks :-)

Just to elaborate - s-nail does not seem to be a drop-in replacement for mailx, so anyone who has need for more up-to-date cipher support may need to move to s-nail while the rest of us can remain with mailx. -- Per Jessen, Zürich (4.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes

On 2023/02/11 11:15:23 +0100, Carlos E. R. wrote:

So far, "-R address" is different.

My mailx-12.5-replyto.patch patch extends -R to can be able to do both open mbox readonly and with address set a REply-To address. But there is more echo test äöü test | ./.obj/s-nail werner@suse.de -s "test" s-nail: -s is an invalid alias name echo test äöü test | mailx werner@suse.de -s "test" allow to set recipient address as first ... ( unsetenv LANG LC_CTYPE ; ( setenv LC_CTYPE de_DE.UTF-8; echo test äöü test ) | ./.obj/s-nail werner@suse.de ) s-nail: Cannot find a usable character set to encode message: No such entry, file or directory /suse/werner/dead.letter 3/55 ( unsetenv LANG LC_CTYPE ; ( setenv LC_CTYPE de_DE.UTF-8; echo test äöü test ) | mailx werner@suse.de ) autodetect UTF-8 mail body on the fly even if outer locale does not set this. All those patches are used by customers which uses mailx within batch jobs and scripts. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

On 10.02.23 17:03, Per Jessen wrote:

For me, mailx is perfect for anything I want to do in batches, and occasionally when I want to send a mail without cranking up TB.

There is another alternative: "mail" from GNU Mailutils. # mail -V mail (GNU Mailutils) 3.15 Copyright (C) 2007-2022 Free Software Foundation, inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. # mail --help Usage: mail [OPTION...] [address...]  or:  mail [OPTION...] [OPTION...] [file]  or:  mail [OPTION...] --file [OPTION...] [file]  or:  mail [OPTION...] --file=file [OPTION...] GNU mail -- process mail messages. If -f or --file is given, mail operates on the mailbox named by the first argument, or the user's mbox, if no argument given.  -A, --attach=FILE          attach FILE  -a, --append=HEADER: VALUE append given header to the message being sent      --[no-]alternative     force multipart/alternative content type      --attach-fd=FD         attach from file descriptor FD      --content-filename=NAME                             set the Content-Disposition filename parameter for                             the next --attach option      --content-name=NAME    set the Content-Type name parameter for the next                             --attach option      --content-type=TYPE    set content type for subsequent --attach options  -E, --exec=COMMAND         execute COMMAND  -e, --exist                return true if mail exists      --encoding=NAME        set encoding for subsequent --attach options  -F, --byname               save messages according to sender  -H, --headers              write a header summary and exit  -i, --ignore               ignore interrupts  -M, --[no-]mime            compose MIME messages  -N, --nosum                do not display initial header summary  -n, --norc                 do not read the system mailrc file  -p, --print, --read        print all mail to standard output  -q, --quit                 cause interrupts to terminate program  -r, --return-address=ADDRESS                             use address as the return address when sending                             mail  -s, --subject=SUBJ         send a message with the given SUBJECT      --[no-]skip-empty-attachments                             skip attachments with empty body  -t, --to                   read recipients from the message header  -u, --user=USER            operate on USER's mailbox Global debugging settings      --debug-level=LEVEL    set Mailutils debugging level      --[no-]debug-line-info show source info with debugging messages Configuration handling      --config-file=FILE     load this configuration file; implies --no-config      --config-lint          check configuration file syntax and exit      --config-verbose       verbosely log parsing of the configuration files      --no-config            do not load site and user configuration files      --no-site-config       do not load site-wide configuration file      --no-user-config       do not load user configuration file      --set=PARAM=VALUE      set configuration parameter Informational options      --config-help          show configuration file summary      --show-config-options  show compilation options  -?, --help                 give this help list      --usage                give a short usage message  -V, --version              print program version Mandatory or optional arguments to long options are also mandatory or optional for any corresponding short options. Report bugs to . GNU Mailutils home page: http://mailutils.org General help using GNU software: http://www.gnu.org/gethelp/ Björn