nmh-workers
[Top] [All Lists]

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

2010-01-28 14:08:30
On January 28, 2010 at 19:15, markus schnalke wrote:

Nmh should try to stay in-sync with Internet mail standards,

This needs steady development of nmh in all involved fields (also
mail retrieval and transfer). By using external tools, only the core
job of nmh (= reading, organizing, and composing mail) needs to stay
in sync. Everything else will be in sync ``automatically''. (I know
``automatically'' is an illusion.)

I think there is a mixing of user-based perspective vs design
perspective that should clarified.  From a user-based perspective,
things should just "work".  How that is achieved under the hood
is a design/implementation detail.

As a user, I should not have to jump thru hoops to achieve basic
expected mail functionality, which includes the retrieval and
submission of mail.

I, as a user, should not have to mess with downloading, installing,
configuring some external app to get basic TLS-based SMTP submission
of email.  I, thru nmh's configuration, should be able to do it easily
("Simple things should be simple to do.").  Now, if nmh relies on an
external package that is bundled with nmh to achieve the functionality,
so be it.

You argue that package creaters should handle all the dependencies, but
that is not always an easy tasks with the myriad of *nix-based systems
out there, include linux ones that repackage things in varied ways.
I've seen numerous user complaints of something not working because OS
packagers decided to break up an OSS application into multiple RPMs,
where not all are installed by default.  Then a user complains to OSS
developers something is not working, when the the problem is because
a part of the app was not installed by the OS packaging system.

Sometimes it easier to just incorporate the external dependencies
into the nmh distribution itself to avoid OS package maintainers to
get things right (some software apps are setup to use an existing
external component if available, and if not, use their version of
the component).  In sum, packaging and installation are important in a
products usability and if users decide to use it.  I've personally had
to use this approach in several projects since reliance on external
packages being installed (and installed correctly) created usability
problems for users.

not
relying on external tools to support features MUAs are expected to
support directly.

``are expected'' is the end in such discussions: Doesn't the world
expect MUAs to be monolithic? Doesn't the world expect web browsers
to be monolithic? (See uzbl.org)

My statement is based upon a user's perspective.  Under-the-hood,
a particular component could be developed externally to the core
product, but it is bundled with the product.  It's just a matter of
packaging and how external components are integrated.

A regular user should not have to know the difference.

Usability matters.  Maybe a question that needs answering is,
"What type of user does nmh target?"  Should an nmh user
be a Unix weenie?

Knowing the target user-base helps determine how nmh should
be packaged and integrated with third-party components.
IMO, basic user-perspective functions should be easy to do
by the user.

Beware of the NIH syndrome. Unix is so good, because it *does* rely
on external software. That's what ``software leverage'' means.

I do not see anyone asking we implement our own TLS/SSL library
from scratch.

Even for IMAP, the discussion tends to lean towards leveraging
an existing IMAP implementation.

I think mail retrieval and submission are core
MUA functions,

We are in total contrast in this point.

They ARE essential from a user's perspective.  I think it is a serious
error to ignore the user's perspective.

It should support the standard mechanisms for its core tasks, yes.
But it should not include lots of stuff that is externally available.
You do use external libraries, why not use external programs?

Real-world experience has taught me that reliance on external programs
can raise serious usability problems.  Therefore, packaging and
integration becomes critical when relying on external components,
either they being libraries or programs.

The basic design philosophy of developing concise-well-defined
components that interact with each other is a good one and most
will agree with it.  I think where the real discussion is is on the
integration of those components.  Is the burden more on the the
application developer-side or the end-user side?  I tend to lean
toward the developer-side to make end-user life easier.

For nmh, my biggest wish is TLS support.  And from what I gather, there
is NO solution that exists for this, either with the nmh core itself
or via external programs.  Neither ssmtp, msmtp, or nullmailer have
interfaces that nmh expects (from what I gather from documentation).
They function as drop-in replacements for sendmail and not as SMTP
proxies.  None support the -bs option, which nmh/MH use when in
sendmail mode.

If an external SMTP proxy solution is adopted, nmh can easily, behind
the scenes, fork/exec an instance when the user selects 'send' or
'push', sends the SMTP commands to the instance for submission,
and then terminate the instance once mail is submitted to the MTA
(or instance self-terminates).  This approach would eliminate the
need for the user to explicitly configure another application, and
any configuration settings needed can be part of the .mh_profile that
nmh can grab and pass to the proxy instance.

Just doing some seaching, I'm wondering if
<http://www.delegate.org/delegate/> could be used.  Looks like it
may support being a basic SMTP proxy that can accept non-encrypted
connections and rely to another host using TLS.

--ewh


_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
http://lists.nongnu.org/mailman/listinfo/nmh-workers

<Prev in Thread] Current Thread [Next in Thread>