Roderick <hru...@gmail.com> wrote:
|On Fri, 26 Feb 2016, Steffen Nurpmeso wrote:
|>|client I feel like. mail(1) was a bit too tedious and limited for
typical
|>|use.
|>
|> Unfortunately i (as the maintainer of the source) have to agree.
|> So it is. Especially regarding interactive use: no way to access
|> message MIME parts directly, and no OpenPGP support, for example.
|> S/MIME limited to the OpenSSL MIME parser. Come back in ten years
|> from now, perhaps. ^.^
|
|We had this thema before. See:
|
|https://marc.info/?t=138009582700004&r=1&w=2
It seems to me that often only patching a codebase is not a good
thing, but especially if it is a codebase that originates in the
1970s and was developed for the machines of the 70s and the
non-existing standards of the 70s. Much has changed, and if you
add and add on top of a base that was designed in totally
different circumstances, then at some time the base is dead.
Regarding S-nail 2013 is a looooong time passing, and it has
a heartbeat. Again. It surely would have been better to take
OpenBSD Mail and use that as a starter, for example, but i was
pointed to that one and i did it. Also i didn't know consciously.
And i'm still alive, no heart attack so far. And the possible
reasons will vanish. YES!
|I agree that mail (1) has its limitations, but in todays form it
|is coherent with the Unix concept and must stay there. This is
|similar to the discussion about lpr/lpd.
I disagree. You need to have MIME to have UTF-8 for example. If
all you need is a cronjob pure ASCII reporter then use what i have
on small Busybox machine, with (possible) some echo(1)es followed
by cat(1) feeding a (restricted version of) sendmail(1) -t.
Right? So for S-nail you can say "make CONFIG=MINIMAL" or even
"make CONFIG=NULLI" and you get only the very basic, but with
MIME. Then give it a few more years and it has been cleaned even
more. (This is at least what i hope. Still.)
|The solution to the limitation is not to inflate it with all kind
|of cool features, but to use an alternative email program with
|the wanted cool features and leave mail (1) there as it is.
It is all i need, really. Or, better, it (S-nail) is all i use
and it would be all i need if it would improve some more. This
regarding user interface and possibilities on the one hand, and
code quality / density on the other. It is very stable, i start
it on monday and quit it on saturday for a long time now.
But you are right. It should effectively be a modularized library
that possibly even has a Lua accessor, with the actual front-end
doing only command-line parsing etc. That is a long road, but the
topic e-mail involves a lot of standards that need to be and that
you want to become handled correctly and no other mailer i know of
except nmh (which i don't know) and of course the superior Plan9
approach to mail handling offer the possible possibility of using
mail from the command line.
E.g., in the queue i have an idea for a very simple frontend for
mlmmj mailing-list archive handling with searching capabilities.
How do you do that? Effectively you use a scripting language like
Perl (with a lot of nice and mature but non-default modules) or
Python (urgh!), or you write a program that uses one of the
available mail libraries. Or you use Plan9 and use grep(1). Or
you use nmh and parse each message a thousand times (i don't know
nmh). Or you could use the BSD Mail and its batching
capabilities, *if* you could use the BSD Mail for that. But you
can't. And *this* is the problem for me. (I'll use S-nail for
this, but it is a terrible and ugly hack.)
|Perhaps in the future we will be able to mount imap mailboxes using
|fuse. Then we can read imap mailboxes with mail (1) not altering it,
Or use Plan9 today.
|this is the unix way. For PGP and mime, mail (1) allows to pipe
|the mail, this is the unix way. Inflating mail (1) and lpr/lpd with
But it's shit. You cannot say "rawpipe" etc. It is not flexible,
not configurable, it is dumb and cannot really be used for
anything real, except by outer intelligence (like signature mark
lines which an external program treats as boundaries). Maybe
NetBSD Mail can do that better, i don't know. I know that S-nail
really sucks in this area.
|cool features is perhaps the linux way, but not the unix way.
I disagree, because a mail handling system needs to be able to
handle mail. I agree with lpr, it is good to have a printer that
understands postscript. I for one hate cups and all that XML
script foo (once i've looked last). Maybe because i don't
understand it. I think it all has become so cheap that a nice
super-simple ARM machine driven by Linux should not only be in the
refrigerator but also in the printer, so that i can feed
postscript/pdf into it directly, and don't need to take care for
the rest. I'd be willing to spend some Euro more for Postscript.
I know for sure that at the end of 1996 a Tektronix laser printer
with Postscript capabilities costed more than 20.000.- German
Marks, so back then cups possibly would have been a good idea.
But cheaper than cheap i really hate, especially if anything that
any point against such a printer (more resource wastage, higher
energy consumption) is not really true in our modern world, where
cheapest parts are used where the stand-by mode lamp consumes more
energy than a complete ARM-based mini computer.
|What is not clear to me, is, if mail (1) for sending emails always
|do smptp to localhost:25 (or :587?) , if one can change this. Perhaps
|there is something to do.
I don't understand what you mean? mail(1) calls sendmail(1) which
does whatever it does. For Heirloom mailx/S-nail you can also
use smtp directly, if you really want to use SMTP/submission on
localhost, nothing should prevent you from doing so. But more
sick things are possible, this mail will now leave my box via
sendmail=/bin/ssh sendmail-progname=ssh \
sendmail-no-default-arguments \
sendmail-arguments="stef...@sdaoden.eu /usr/sbin/sendmail -t"
for example.
¡Hasta la victoria siempre!
--steffen
