[2010-01-27 20:53] Ken Hornstein <kenh(_at_)pobox(_dot_)com>
We've already seen numerous examples of people providing
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
useful, even a bazillion years ago.
History may have been bad. However, it may teach very important
lessons. One should never ignore it, but one should go new ways if
appropriate.
Both MTS's will continue to be
supported for the foreseeable future. Anyone is free to configure nmh
however they want to meet their needs. What, exactly, is the problem here?
The problem is, that we should:
``Write programs that do one thing and do it well.''
And as for it being _easier_ ... well, literally, configuring the SMTP
MTS is as simple as placing this in your .mh_profile:
I personally, don't care much about easy, but I care about right.
(Especially, as this is what nmh does better as any other MUA.)
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)
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.
Fetching mail is also the job of a different tool.
``Write programs to work together.''
Okay, nmh consists of many programs that work together, but nmh should
not strive to be self-contained. Don't let the NIH syndrome rule!
Nmh should work on a mailbox in the local filesystem. Incoming mail
should enter as plain-text through inc. Outgoing mail should leave as
plain-text to an MTA.
Three sentences to to define nmh's external shape. This is the
simplicity of Unix. This is how it should be.
I also take objection to your subject line. This has been hashed
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
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.
Yes there is:
``Write programs to handle text streams, because that is a
universal interface.''
(I admit, this does not exactly match the point.)
We could avoid the SMTP protocol implementation, and thus a lot of
complexity, by simply piping to a command.
I know the reasons why it is like it is. I know, that some things look
easy in the beginning. But in the end, what matters are simplicity,
clarity, and generality.
On one of your best days, you through a thousand lines of code away to
make the program simpler, clearer, and more general. And then you write
a tutorial on how to use some existing external tool to do the work it
can do best.
You probably recognized, that I quoted Doug McIlroy's view on the Unix
Philosophy. In my eyes, he's the one who knows best.
meillo
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers