On Wed, Aug 23, 2000 at 09:21:58AM +0930, John Pearson wrote:
> Well, that certainly indicates one reason why I'm having difficulty coming
> to grips with your requirement; we have a problem over terminology.
Actually, we don't. The problem is that people aren't willing to look
past the terminology. For instance, your examples below have a flaw in them.
> I differentiate between MUAs, MDAs, and MTAs; examples are:
> MUA: mutt
> MDA: procmail
> MTA: exim
MTA: Exim. Exim does not need an MDA as it fills that role as well. So
it could be something like this:
MUA: mutt
MDA/MTA: exim
> Obviously, you mean something different to MUA to me (and, perhaps, others);
> what, in your view is an MUA if not a mail client?
No, I mean exactly what an MUA says it is. Mutt is an MUA but, to me, it
is not a mail client. A mail client is able to transfer and manipulate the
required data without need of other programs. A constant example I give,
which is flawed as all are, is web browsing. A web browser is, for the most
part, an HTTP client. We have the HTTP server and the HTTP client talking to
one another directly. We don't have an HTTP transport agent to get the data
to the HTTP user agent. Again, example, it is flawed, but it gets the basic
point across.
A mail client does most, if not all, of the tasks defined as an MUA and
most, of not all, of the tasks of an MDA with some minor tasks relegated to an
MTA. Let me try to explain.
MUA: Program to manipulate the mail databases, filter through them, display
them and perform functions upon them as well as limited support functions to
help in that main task. IE, reading, replying, deleting, moving messages
around are all the main task and the address book, for example, would be a
support function. Editing text, spell checking, contact lists, etc are all
separate applications and, to me, are not part of the MUA.
Do you feel this adiquately describes the majority of functions of mutt?
MDA: Program to deliver mail to the local system in accordance with any
directives given. This includes any file locking specific to the file system,
filtering that is requested from the user(s) as well as system
administrator(s) and so on.
Exim's MDA portion and procmail?
MTA: Program to deliver mail to external sources as well as accept mail from
external sources for later redistribution to either the local system or
another, external system.
Exim's MTA section, Sendmail?
Now, let's look at what the mail clients, not MUAs, do. We'll keep it to
a single mail account for simplicity and to set aside the whole issue of how
to handle multiple mail accounts. A mail account, as I described to Brian
earlier, is a collection of folders, filters and settings that are independant
of other mail accounts.
A mail client attaches to a remote server and pulls the mail down. This
is, technicaly, MTA. Once it has the mail it applies a series of filters to
it (MDA) and stores it in local folders (MDA). There it allows the user to
read, reply to, move and delete those messages (MUA) as well as other support
functions (MUA). When they send a message out the client once again connects
to a remote server and hands off the mail for delivery (MTA).
Now, adding multiple mail accounts back in I feel that a mail client
should be able to do that for each mail account with each having its own set
of incoming and outgoing servers, filters, folders, settings and so on. This
means a single instance keeps the sent mail separate, uses different SMTP
servers dependant on mail account (which is independant of mail addresses and
local accounts), to the point where a mail account can and should be able to
be moved from one machine or local account (local = user, to clarify) without
problem. That is different than the "personalities" paradigm which does not
separate out sent mail, use separate SMTP servers and otherwise does not keep
the incoming mail separate as the default.
Anyway, getting back to the question(s) about MUA/MDA/MTA and mail client.
I feel there is a difference between the MUA and a mail client. I do not see
a problem with a mail client incorporating portions of other roles because
they logically fit together in certain circumstances. The MUA/MDA/MTA
divisions were made in the day when there were multiple (dozens to thousands)
of people on a single machine and a single mail account as associated with a
single local user account. I'm going to assume that anyone still interested
in this thread knows why that is the case. If not there is good reading in
the bat book on the subject.
However, that is not the only case today. I feel that the MTA/MDA/MUA
division is overkill for a single person on a single box. There is no need to
set up an MTA in that case. It will be running in smarthost mode forwarding
all mail to another SMTP server to do the actual delivery. I am certainly not
advocating a complete MTA be programmed into a mail client, but I don't see
how having the basic "send, if it fails, try later" semi-smart host setup is
unreasonable. I also feel that it is not unreasonable that the client handle
its own incoming transport and, as a result, its own filtering on that
transport. As I said, we don't have HTTP transport agents, FTP transport
agents and Telnet transport agents. Thge *TA layer is good when you're moving
multiple outside sources to multiple inside sources. For example, mail to
multiple people on a machine, MTA is appropriate. In HTTP it isn't called a
"transport agent" it is called a "proxy" or "caching proxy". I said the
example before was flawed. ;)
However, in all of this I feel people have taken the knee-jerk raction of
"either/or" when I have never stated that is the case. Remember, I said a
mail client encompasses all of an MUA, most if not all of the MDA and some
MTA. I never said it was to the exclusion of all others. I do feel a proper
client could be used as an MUA with no problems. IE, an MTA and MDA deliver
to mailboxes that the client reads. In fact, I see no problem with that
happening in conjunction with its own fetching and filtering on other or the
same mail account(s). I never once said that it was proprietary format,
either. All of those, in he course of this thread, have been attributed to my
stance even though I've never stated them. Not saying that you did, John.
Finally, as I described to Brian, the reason for the idea of mail accounts
and the separation that they describe is not a technical one, it is a legal
and security one. Yes, the schemes presented here satisfy the technical
reasons to some degree and some arguments could be presented for the
"foolishness" of other proposals because of the technical reasons on why they
are foolish. However, technical reasons rarely win out against corporate or
government policy. For example, even if one has IMAP servers on both sides of
a personal/professional split and can reasonably read personal mail from work
because of it there is still the issue of sending personal mail out of the
professional server that could get people in trouble. Conversely I /know/ I
can read my work mail from home and, again, if it were IMAP (to get around
other sticky issues) there could be policy that corporate mail is /not/ to
traverse any outside mails server, including my own. Those are simple
problems that are not easily solved in the MTA/MDA/MUA context nor easily
shoehorned into that context for the very simple fact that the MUA is designed
to use a single MTA server and often it is the local one. To maintain
separation is a pain in the butt because that separation isn't the default.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------
