[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] mts.conf has me Baffled.
Re: [Nmh-workers] mts.conf has me Baffled.
Sat, 25 Jul 2015 00:57:45 -0400
>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
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,
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"
>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
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
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.
Re: [Nmh-workers] mts.conf has me Baffled., Ken Hornstein, 2015/07/27