You obviously don't use "send -push". I do, and have almost forever.
Without that, sending mail is way too slow for me, I'd never (at least in
the past when sending e-mail was more important to my work/life) get
anything done if I had to wait for mail submission to finish before getting
on with the next.
Err, really? Here's an example of "send", performing SASL/GSSAPI
authentication (3 complete round trips) with session encryption over the
global Internet from my home to work. Also, the draft in question is
on a network filesystem:
% /usr/bin/time send -draftfolder +drafts -draftmessage 1
0.31 real 0.01 user 0.01 sys
Unless it's a large file, I have never really notice the time it takes
really impacting me at all (there is some variance ... a few more runs
shows it can take as long as 0.71 seconds). I am aware of -push, but I
always put that in the "expert mode" box. If you're turning that on,
you should be aware of the consequences. It's not the default for a
reason.
Just as a comparison, here's me sending a draft through pobox.com, my
commerical email provider:
% /usr/bin/time send -draftfolder +drafts -draftmessage 2
0.68 real 0.01 user 0.01 sys
That's with PLAIN authentication but it is doing TLS encryption. There's
no cheating here; in fact, my setup is probably slower than most (in addition
to running mhbuild, I have a custom postproc that ends up calling "scan"
on the draft to determine the From: header to decide which server to send
the draft to).
It isn't even all that unusual, I often do (or did) a lot of mail sending
from on planes, where they (at least did, these days sometimes it is
more possible) frown on using (even attempting to use) any kind of
network connection - yet it is an ideal place, with few interruptions, for
catching up with lots of pending messages. But only if sending works,
eventually.
I'm aware of that as well (although perhaps I would quibble with "not all that
unusual", but fine). But again, I'm going to put that in the "expert mode"
category.
What's more, aside from being more restrictive, config that way also
tends to be easier.
Fair enough, we agree on that.
| So when you say, "really not all that hard", you're speaking as
| someone who's been in and out of the deep
| levels of Unix for many decades.
Actually, no - I really mean "not all that hard" - it cannot be, or the
OS "vendors" (in quotes, because nmh is I think most commonly used on
free systems) would never survive - it all has to be no more difficult
that anything else to set up, and generally isn't.
Sigh, Robert, please see below ... the OS vendors don't care if mailx
doesn't work for home ISP users! They don't! They don't care because,
essentially, all popular MUAs just configure the smarthost and do SMTP
submission directly, bypassing the local MTA? Why do you think they do
that? And generally isn't more difficult than anything else to set up?
I'm not even sure what that means; in my experience there is a WIDE
range of difficulty on what it takes to set stuff up on a Unix system.
The most recent issue was (I believe) with someone whose mail system in general
was working fine, but couldn't get nmh set up to use it easily. nmh config
was the harder part. It doesn't need to be.
The reason I asked if you read all of the messages because that
is NOT how I interpreted the most recent issue. Martin wanted to
use a different MTA just for nmh, not the entire operating system.
Specifically, the reason given was because exim4 (the operating
system-supplied MTA, which was primarily used to send local emails):
| What it doesn't do very easily is contact a smtp mailhost that requires
| a TLS-based authentication mechanism that msmtp does handle more
| intuitively.
Nowadays that sort of thing is standard for home-based ISP connections.
To be fair, Martin did mention that exim4 is relatively easy to configure
to punt all non-local email to a smarthost (the standard for enterprise
configuration, in my experience).
So, Martin was trying to use an alternate MTA, specifically msmtp. But
as it turns out, msmtp doesn't really provide a sendmail-compatible
interface. Specifically, it doesn't support the -bs flag which nmh
needs. You can run nmh in a mode where that isn't required (the old
days you did that with "spost", but nowadays you use "sendmail/pipe"),
but you lose functionality.
Now to be fair, Martin did have a few nmh configuration issues. Those
were leading blanks in mts.conf for one entry, and he didn't quite
understand exactly what we meant by "sendmail/smtp" and "sendmail/pipe".
I thought at least the latter was straightforward, but if we need
to improve documentation then that one is on us. I can't really blame
anyone else for our lousy configuration file parser, though.
| - most systems nmh will run on tend to come (almost) set up that way out
| of the box anyway
|
| "almost"? To me, that means that it's NOT configured! It doens't work!
We all agree something needs to be configured to know the ISP's smarthost
right? (At least in common configurations). Do you really think it best
that that be every MUA on the system (if nmh is there, then there will be
at least 2, probably more - all with different config mechanisms) or would
it be easier to do just once, for a local (submission capable) MTA that
all the MUAs can be set up to use straight out of the box.
In theory, I'm with you on that; it would be easier. It's just that
a) most MUAs don't even have the option to submit to sendmail and b) the
MTAs I'm used to are very complicated, so they have lots of knobs; it's
hard to drill down in the documentation to find the bits you care about.
MH used to
default to that, and required no config to be able to send mail if anything
else on the system could do it.
Weeelll ... not exactly. I took a look at MH 6.8.5, and the default setting
was ACTUALLY:
mts sendmail/smtp
From mh-gen.8:
On UNIX systems supporting TCP/IP networking via sockets you can
add the suffix "/smtp" to the mts setting. This often yields a
superior interface as MH will post mail with the local SMTP server
instead of interacting directly with MMDF or SendMail.
Realy, what that meant was that "post" would talk SMTP to a submission agent
(except they didn't call it that back then). It would use the entry for
from the "servers" line, which defaulted to:
servers: localhost \01localnet
So if you ran an SMTP server listening on localhost, that's what MH would
try to send to by default (the \01localnet meant it would try each server
on a local network looking for one that ran a SMTP server). mh-gen(8) later
went on to say that you should make sure you set the "servers" entry
appropriately. I do recall it was pretty common back then to run on
every host a copy of sendmail which listened on port 25. If you had that
setup, MH would indeed "just work" (although I recall it tended to put
the local hostname in your From line, and we never wanted that so we had
to do masquerading on the server). But ... that was a different time.
I'm not so sure that's relevant for today.
| I could certainly see that users might want to know about network issues
| and have a chance to correct them instead of having email silently queued.
Depends what the issue is. A one minute glitch while my ISP decides that
it is time to reset my connection so it can give me a different IP address
in the hope of preventing me running any kind of servers I prefer not to
know about at all ... it corrects itself, fairly quickly. A "problem"
caused by being on a plane isn't something I can do anything about.
Fair enough; I know we're never really going to agree on this one.
If we did, yes, that would be horrible. But the sendmail interface is
so common these days (the basics are provided by just about everyone)
Unfortunately, that's not really true as we've seen with msmtp. Well,
I guess it all depends if we consider "-bs" part of the basic interface
or not; I know things like postfix support it.
Then the nmh MTA config can be available for people who want to have more
control or do things in different ways - but people should not be forced
to configure nmh at all, they should be able to just install & use it.
Well ... unless we're arguing about the defaults, I don't think anyone
is being forced to do anything. You can change the mts at runtime, which
in my mind is a huge improvement over MH (god, I do NOT MISS the old
mhconfig program! Smell you later, mhconfig!). I mean, I understand your
point about making it work for all MUAs, but the reality is that
configuring the MTA harder, and really, most modern MUAs just submit
to the smarthost directly. So you're only fixing it for things like
mailx and nmh; a pretty small pool.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers