In the message dated: Wed, 27 Jan 2010 20:53:46 EST,
The pithy ruminations from Ken Hornstein on
<Re: should nmh be an MTA or an MUA? (Was: Re: [Nmh-workers] nmh @ gsoc?)> were
:
=> Have we not beaten this subject into the ground yet?
=>
=> >Here's where we differ. For me, it's "easier" to configure sendmail, so that
=> >the nmh configuration remains the same in any network environment.
=>
=> Alright ... so, my answer to this is: So what?
=>
=> Yes, it's easier for _you_. Great. But that doesn't translate to easier
=> for _everyone_. We've already seen numerous examples of people providing
I never said that my was was easier for everyone...hence the use of the wording
"For me..."
I was simply offering a counter-example to a use case that you proposed as an
absolute.
=> legitmate reasons for using the SMTP MTS. The SMTP MTS is not a new
=> feature in nmh; it's been there forever. Clearly people thought it was
Right. Been there forever, with little maintenance (as evidenced by all the
calls for TLS support). Building more MTA features into nmh is kind of like an
arms race...without on-going maintenance to keep up with the requirements being
introduced by ISPs, corporate environments, etc., nmh will often be unable to
send mail.
On the other hand, dedicated MTA tools are under faster development cycles, and
can be used in more environments.
=> useful, even a bazillion years ago. Both MTS's will continue to be
I'd argue that the MTA within nmh was more useful a bazillion years ago, when
Vaxen roamed the earth and when there were fewer mail/authentication/security/
transport protocols.
=> supported for the foreseeable future. Anyone is free to configure nmh
=> however they want to meet their needs. What, exactly, is the problem here?
Configuring nmh isn't the problem. If TLS support existed, it still wouldn't be
a problem.
The problem, as I see it, is limited resources for maintaining and enhancing
nmh, as evidenced by the slow pace of development. The question that's being
posed is where it is best to spend those limited resources. I suggest that
adding MTA functions into nmh which already exist in external tools that can
easily be used by nmh is not a good use of resources. You obviously disagree.
=>
=> And as for it being _easier_ ... well, literally, configuring the SMTP
=> MTS is as simple as placing this in your .mh_profile:
=>
=> send: -server your.mail.server.here -port your.mail.port here
Yes...if nmh supports the protocol...which seems to be in question.
=>
=> >There's already
=> >extensive support in popular MTAs (sendmail, postfix, etc.) for multiple
=> >delivery mechanisms (TLS, POP-before-SMTP, SMTP AUTH, MSA, etc), so
=> >this doesn't need to be duplicated in nmh. I prefer to let the MTA accept
mail
=> >from nmh and then do the external transfer for me.
=>
=> This is a bit disingenuous; of the things you list, only one (TLS)
Perhaps a bit sloppy on my part, but not disingenuous. I wasn't attempting to
give a comprehensive list of mail protocols, nor did I ever say that nmh did
not support those protocols. I was simply listing things off the top of my head
to illustrate that there are many protocols, and that external MTAs offer more
support.
=> is not supported by nmh. And honestly ... POP-before-SMTP? It's
=> not like you need to do anything to your client to support that.
=>
=> I also take objection to your subject line. This has been hashed
Why not take your objections right out the door.
The amount of discussion makes it clear that this is still a point of interest.
=> out extensively on this list; when using the SMTP MTS, nmh is _not_
=> acting as a MTA, it is not looking up MX records and performing
=> final delivery. It is, in fact, acting like the large majority of
I'm not going to spend half my day reading RFCs to see just how "MTA" is
defined. The "post" manual page has references to both delivering mail directly,
and to interacting with a local MTS (sendmail is given as an example).
To me, it walks like an MTA and talks like an MTA.
If you don't want nmh to "act as an MTA", then why do you want to extend it's
MTA-functions, instead of having it interact with a real MTA (the intention of
post(8), as I read it)?
It sounds like you want some of the features of an MTA (in this case, TLS), but
not a full implementation. I can see why some people want that, and why the
limited scope looks like it's consistent with the original [n]mh design in
providing some transport functions. However, the original design came at a time
when there were fewer SMTP options, and relied on tools outside nmh (ie.,
post(8) didn't have a uucp client). Does it make sense to put resources into
providing functions that have already been implemented--and are being
maintained--in MTAs that nmh is designed to interact with?
=> MUAs today (certainly any graphical email client) and using the
=> SMTP protocol to submit email into the email system. This is a
=> recognized and standardized method of injecting email into the
=> network, and there is absolutely no reason for nmh to not support it.
As I see it, there are two arguments against increasing MTA functions in nmh:
that the "Unix philosophy", of which nmh is a prime example, is for
small tools that each do limited tasks well, and which interact
to create larger functions. In this instance, the MTA functions may
be provided outside the scope of nmh.
that there are limited resources for extending and maintaing nmh, as
evidenced by the fact that the TLS enhancement hasn't happened already
Given unlimited resources, added TLS support would be tiny "feature creep",
and a welcome enhancement for many people.
Mark
=>
=> --Ken
=>
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers