On Wed, 16 Jul 2003 04:14:42 -0700 Paul Johnson <[EMAIL PROTECTED]> wrote: > Because it's pointless and un-necissary to impliment the better part > of an MTA into an MUA.
Which is why you don't do that. Smarthost doesn't need a full blown MTA
to do it. This is smarthost behavior. Here are the steps involved:
Lookup DNS
Connect
Process
That doesn't look like an MTA to me.
> One program, one function. It really does just work better that way.
I agree. However I do not subscribe to the theory that mail clients are a
class of clients unto themselves which cannot handle their own transport like
every other class of clients in the server/client model.
> That whole thirty seconds of thinking and keypoking at eximconfig to
> take a stand against bad MUA design is *not* going to hurt you, no
> matter how many software ads tell you komputers is hard and that's why
> their (slapdash, profiteering, wrong) way is the only way and thinking
> otherwise will cause pain.
Lemme give you a little background. I've been using computers since 1982.
I missed the acoustic 300bps modems by a few months. I owned an 8086 class
computer when that was all there was. I've been using Linux almost as long as
there has been a Debian distribution. In fact I think when I started there
was Slack and Yggdrisl (sp?) and that was it. My first installed Debian
system was before the move to libc6. I argued *for* Exim when it became the
default way back when because I had been running it instead of the default
(sendmail, was it?). Since then I have had a Debian system running Exim
24/7/365 with very little downtime.
IE, I am well aware of the unix design philosophy. I agree with it
wholeheartedly. I am not scared of Exim or its conffile, nor Linux nor a slew
of other such assumptions that were in your rather loaded paragraph above.
> All of them, with the exception of ones that were ported from windows
> (Mozilla, Netscape), or the ones that make similarly bad design
> decisions as the Windows MUAs (kmail and any other MUA that thinks
> it's also half an MDA or MTA), because they make the safe assumption
> that transport is not the user agent's job (it's not, that's the
> transport agent's job).
I ask again, what do those mail clients do when the MTA is not present?
What does, for example, mutt do when for some stupid reason $MTA is
misconfigured by the user? I asked what they did if it were unavailable.
Unavailable can take a plethora of forms other than "not installed". User
misconfiguration, annoying BOFH which prevents users from running the local
MTA, etc.
> Also, cron is a required component of the system, which depends on an MTA.
> How else is it going to give users output? Osmosis? Telepathy?
Log files?
> > Clearly it is an error condition and something must be done about
> > it.
> Actually, I think it more clearly demonstrates that you got your idea
> of software design from the Windows world, which ignores real-world
> stability and security issues.
Uh, no. It is an error condition. For some reason or another the local
MTA, through user misconfiguration, lack of install, bad permissions, etc is
not available. That is an error-condition that has to be dealt with. What do
the clients which assume the MTA will always be there do in such an instance?
> And most people also don't like waiting on their confused half-an-MTA
> to sit there and spin when something it's tiny brain can't handle
> happens, like destination SMTP server got yanked out from under them.
Oddly enough I have never had a single mail client which does access the
MTA "sit there and spin when something it's tiny brain can't handle happens".
Every single one fails gracefully. The most graceful was one which
automatically threw the message back into drafts and reported an error to the
status bar. I have been, in the past 7-8 years of using clients who do their
own communicating in the client/server setup been able to go about my business
when, for one reason or another, the MTA was not available.
> At least with a real MTA operating in parallell to your MUA (the right
> way), your MUA hands it off and lets you keep moving with your day
> instead of waiting on delivery or leaving it floating around limbo in
> some outbox.
And, more often than not, it also bounces the message which forces you to
go back, clean up the bounce, try to resend when you remember and delete the
bounce. I prefer the outbox, thanks. The same client as above had an option
to try to send again the next time you retrieved mail. Was quite painless
when I didn't have my connection up. An option the MTA puked over constantly.
> If it runs into a problem, you get the bounce just as fast either way, and
> if you're offline, it'll get sent next time the link comes back up
> automatically, even if you're not logged in.
No, you get a bounce faster in the matter of just blindly handing off to
the MTA. Oh, and to answer my oft-repeated question most MUAs that presume
MTAs are there are incapable gracefully handling it when it isn't there. The
last one I checked, mutt, wouldn't let me exit the menu until I postponed the
message. Stark contrast to the client that tossed me an informative error and
handled the error without stopping me in my tracks. It seems to me that it is
your case that spins its wheels when its tiny brain hits a condition (an error
condition) that it cannot cope with.
> Considering how much easier to configure the MTA once and let it run
> versus telling everybody how to set up a bastard MTA/MDA/MUA program,
Ease of configuration is a relative term. I have played the exim/mutt
game (using Exim's filters) and have played with
sendmail/fetchmail/procmail/pine ages ago. I absolutely hated the
configuration because I had to constantly tweak it to do even the most trivial
things. Heaven forbid I want to do anything advanced like use the same client
to check two accounts and keep them completely, totally separate. Any
operation the clients I use do with minimal configuration in about 20
minutes that take hundreds of lines and several hours of work with the painful
MTA/MDA/MUA combination is not in any way easier in my book.
> I can't even understand how this design became so prevelant on any
> platform...
Because we're not back in the mid-80s with hundreds of people on a single
machine and only one mail account. Hell, the last time I was on a
machine that I received mail on that had other people occupying it was around
1993. It was a shell account at Netcom.
The design became so prevalent because it makes sense. Let's look at just
a few examples that the MTA is incapable of handling or takes a hell of a lot
of configuration to handle that a properly designed mail client handles
easily.
Let me give you just a few examples on situations I found the MTA/MDA/MUA
chain severely lacking. You'll note they are not uncommon and most stem from
just one situation: having a job.
1: Lack of separation of mail accounts.
Because I had a job I had a work account and a home account. Let me
clarify. A work *mail* account and a home *mail* account. It was entirely
unacceptable for me to even think about mixing that mail at any time. The
MTA/MDA/MUA chain fails this utterly. Under that chain there are only two
options.
Option A:
work\
> -> fetchmail -> MTA -> MDA -> MUA
home/
This is unacceptable because at the MDA I would have to filter out the
mail which started out separately in the first place. Right off the bat we
have an overhead of at least 1 to 2 filters. Worse is the MUA having no
concept that there are two accounts at all. So now I have to go into the
MUA's configuration and tell it, for each folder, which "personality" *SPIT*
to use. At the time my home account had 30+ folders and work had as much if
not more. So for 60+ folders I have to tell it "no, use *THIS* address, not
*THAT* address". I also have to do that every time a new filter and folder
are made.
Even worse than that (talking specifically mutt here) I couldn't
tell what folders had new mail in it with a concise display. "goto next
folder with new mail" didn't help because there were some folders I could
ignore most of the day and only needed to review once. I'd hit those folders
every time I just went slamming on that key. I'd either have to do that or
check the folders every so often to see what new has popped up. Bad if I'm
sitting in my home account folder and my boss sends me mail he wants a prompt
reply to. That's partially answered by some clients allow you to determine
which folders to watch for new mail. Great, another option to put on 20-30
folders and still doesn't help on the folders I only have to review so often.
Finally I have to also remember to tell it to copy the sent-mail to
different locations when it delivers. Yay, even more rules!
Option B:
work -> fetchmail -> MTA -> MDA -> account 1 MUA
home -> fetchmail -> MTA -> MDA -> account 2 MUA
Simply put, no. Why should I have a completely separate account to check
another mail account? I don't have separate accounts for different FTP sites,
web sites, new servers or any other server/client. So why this one. Same
goes for multiple configuration files. I am not going to run two copies of
the client just to get mail from 2 locations. What happens if I want to keep
other mail separate? Another instance? Another account? That doesn't scale
well, does it?
2: MTA couldn't handle multiple locations easily.
I checked mail at home and at work. I couldn't send work mail through my
home sharthost or my home mail though my work smarthost. So now I am supposed
to get the MTA to divine that mail from this address is to be sent via one
smarthost and mail from that address is to be sent via another smarthost? I
could just look at the destination except at my job I communicated with lots
of people outside my place of employment. None of that mail could go to my
personal MTA. For legal, ethical and technical reasons.
So, what does that leave? The clients I have been using. This is how
they work. You can define multiple accounts. Each account has it's own set
of folders, filters and settings. Completely separate. IE:
work\ / work filters -> work folders
> -> client <
home/ \ home filters -> home folders
So let's take a simple 2-account setup.
Client:
Create work account, define name, address, pop server, smtp server.
Create home account, define name, address, pop server, smtp server.
As of right now the client can do the following things:
* poll both accounts and deposit mail in the appropriate inbox
* compose/reply mail in either account without the user having to define what
address or name to use.
* send mail to the appropriate smtp server no matter what the location.
Just to do those three basic things what steps do we need to take for the
mta/mda/mua path?
1: Setup MTA to try to decipher which SMTP server to relay what mail to. This
is automatic in the above example.
2: Setup fetchmail to actually retrieve the mail, shove it to the MTA or MDA
and tell it which user to deliver to.
3: Setup the MDA to filter the mail into two different folders.
4: Setup the MTA to look into both folders for new mail.
5: Further configure the MTA to use one name/address for one folder and
another for the other folder.
6: *FURTHER* configure the MTA to save mail sent from one folder in one place
and from the other folder into another place.
7: Whoops, two more folders we need to configure for the proper name/address.
The top is about 2-3 minutes of work; even for a layman. The bottom is at
least 20. More if you're not familiar with any of the steps involved.
So let's add a mailing to the work account.
Client:
Create new folder in work account
Create filter to direct mail to that folder (note that this has the added
benefit of work filters not working on home filters).
Chain:
Create filter for new folder.
Configure MTA for which name/address to use for that folder.
Configure MTA for where to place sent-mail for that folder.
Again, the client that does the work it should has a far easier
configuration. Since there is the concept of mail accounts which are not tied
to the login account any time we create folders/filters/etc. in that account
they act only on that account and derive sane defaults from it. The chain
requires us to explicitly configure it every time.
But wait, there's more! How about that schnazzy protocol, IMAP! To get
the most out of that protocol one would not want to use fetchmail since it
treats it as a glorified POP server. Your mail access from a client. Darned
if the client has to do the communicating there, too.
No, the MTA/MDA/MUA chain worked ok up until about '93 when the general
population started getting personal SLIP/PPP connections and the opportunity
to have more than one mail account. A decade later where clients handling
multiple mail accounts makes for sane mail handling without gobs of wasteful
configuration. That's why it has become so prevalent.
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
| -- Lenny Nero - Strange Days
-------------------------------+---------------------------------------------
pgp00000.pgp
Description: PGP signature
