MUA stands for Mail Use Agent or Messaging User Agent. MTA is for Mail
Transfer agent. There is a third, MDA, which stands for Mail Delivery Agent.
Now, as always, I'm sure someone like Alex could come up and point out
where I am wrong, but this is my understanding of these terms, why I use them
in the way that I do and how they shape my thoughts and views on the whole
technical and social mechanisms of email.
Each of the three terms, MUA, MTA, MDA, describe not programs, but roles.
This is an important distinction since some programs could easily be several
of the different roles.
The MUA is the role of being an interface to the user. It allows the
user to read and prepare mail for sending. This is all an MUA does.
The MTA is the role of moving mail from system A to system B in a secure,
speedy and proper manner. This is all an MTA does, move mail.
The MDA is the role of actually delivering mail once it is on system B.
This delivery might include further steps as delivery includes the filtering
process.
The main focus of most email clients is to fulfill the MUA role. However,
they also fill other roles. For example, TB! is an MUA (let's you
read/prepare mail for delivery), limited MTA (POP/SMTP transfers), limited
MDA (filtering mail into different folders is delivery) as well as a text
editor, a spell checker and other things.
This is why in the previous thread I said that the expected behavior of
TB! conformed to those of MUAs through the years. Not all email clients to
everything that TB! does but the portion of the email client we were talking
about, preparing a message to be sent, falls clearly in the MUA role.
Now, here's where a lot of people would get up in arms with me. They have
on other lists, newsgroups and, I believe, even here. I feel that neither the
Windows world or the Unix world have gotten the concept of "Email Client" down
correctly. Both have clients, sure, but the roles (and lack of roles) they
take on are flawed.
In Windows the problem is all of the clients implement too much. For
example, TB!, as stated, is an MUA, limited MTA, limited MDA, text editor,
spell checker & LDAP client. I feel that the text editor and spell checker
should be left out entirely and only hooks into a text editor provided. The
text editor would then not implement a spell check but, instead, provide hooks
to call one. In this way each person can use the editor they prefer and spell
checker they prefer. In fact, they could use the editor/spell checker across
a variety of programs and in doing so have a consistent interface for those
two portions across those programs as well as the ability to choose the best
editor/spell checker for them. This would free up time for the authors of the
mail client to work on the mail client instead of reimplementing an editor and
a spell checker which will always be subpar to the editors and spell checkers
from authors who are programming them and not them and an email client as
well.
In unix the problem is that most, if not all, of the clients implement too
little. Hardly any clients are as capable as TB! and PMMail98 on checking
multiple, separate accounts. Most cannot filter mail but, instead, rely upon
a program designed to fill the MDA role to do the filtering. Because of that
paradigm most also do not handle POP/IMAP with any intelligence at all.
However, they don't encumber themselves with editors or spell checkers and,
rightfully, simply provide hooks to other programs to handle those specialized
tasks.
A lot of people have argued that an editor and a spell checker (for
example) are required in producing mail and thus should be reimplemented by
the authors of each individual email client. A lot of other people argue that
separate tasks should be handled by separate programs. So how do I reconcile
the need to combine some tasks (MUA/MTA/MDA) but not others (editor/spell
checker) into an email client?
The key lies in understanding what the primary function of an email client
is. An email client is, at the core, a program which handles a database.
That database is what we call "messages." With any database there are
functions which need to be there to make it functional.
1: Import
POP/IMAP/local spool files provide this functionality. Therefore a proper
email client should be able to retrieve its own mail from remote servers as an
import function.
2: Sorting
Not only does this apply to what is already in the database, but also what
is coming into the database. If the client must be able to import (retrieve)
messages from other servers it means it must also be able to filter them.
3: Export
Finally, what good is a database if you cannot take the data that is in it
and move it elsewhere. SMTP provides this functionality.
4: Maintenance
Finally routines need to be provided for the maintenance of the database.
The ability to trim it of cruft, move records around, perform backups and so
forth.
As you can see, #1 & #3 require that the email client implement portions
of the MTA role otherwise it is, IMHO, crippled. #1 dictates that a portion
of the MDA role, filtering, be implemented since it is, in essence, delivering
to itself. It cannot rely on external filtering. #4, well, #4 has not been
fulfilled to my satisfaction in any capacity. Anyone who has run a BBS during
the heyday of the BBS would know what proper message base maintenance is.
This is an area that is severely lacking.
As you can see, however, the importing, sorting, exporting and maintenance
of the database does not require the roles of editor and spell checker. Those
are two highly specialized tasks which are independent of the core
functionality of the email client. Just as you would not expect every editor
to implement spell checking or to be able to read mail (emacs not
withstanding) you'd not expect an email client to provide editing
functionality or spell checking or a spell checker to edit text and check
mail.
For those who insist that an editor and spell checking are just another
imput, consider this. There is a protocol for getting mail from a remote
system. In fact, there are two. POP and IMAP (well, SMTP as well, but that
isn't a client protocol as much as the other two are). Just as there are
protocols to interface into remote systems there should be a protocol to
interface into a general editor. Just as one would not reimplement a complete
SMTP server just for an email client and just provide the requisite protocol
for the interface, the same goes for the editor.
Long winded message to be sure, but it should clear up some of the terms
that I use and describe the position from which I argue from when it comes to
a lot of things relating to the email client.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
--
--------------------------------------------------------------
View the TBUDL archive at http://tbudl.thebat.dutaint.com
To send a message to the list moderation team double click here:
<mailto:[EMAIL PROTECTED]>
To Unsubscribe from TBUDL, double click here and send the message:
<mailto:[EMAIL PROTECTED]>
--------------------------------------------------------------
