[2010-01-27 20:53] Ken Hornstein <[email protected]>
>
> 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
[email protected]
http://lists.nongnu.org/mailman/listinfo/nmh-workers
