[Nmh-workers] Re: should nmh be an MTA or an MUA?

[markus schnalke]

[2010-01-27 20:53] Ken Hornstein <address@hidden>
> 
> 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