Re: mail clients
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 22 May 1999 18:20:27 -0700 (PDT), George Bonser wrote:
>On Sat, 22 May 1999, Stephen Pitts wrote:
>> Mutt/fetchmail/exim works fine for me, with 2 accounts. Contrary to popular
>Mutt is a non-option for most users who want the functionality of Outlook.
>Things like drag/drop and shared folders are very important in that
>context. Mutt would get laughed out of the room.
OK, let me jump back in here for a moment. The whole reason I have yet to
switch my mail reading to a 'nix client isn't GUI considerations. I know that
isn't your point here, George, just using your message to take a tangent. ;)
My main beef is that most, if not all, 'nix clients consider all mail that
comes into a physical account also coming into the same virtual account. This
is especially true with the fetchmail/[procmail|exim]/mutt route. However, it
is also true with Outlook Express, Eudora Pro, etc.
What I am used to using is an MUA which treats each account as a
completely seperate entity. Seperate POP/SMTP servers, seperate from lines,
seperate signatures, seperate filters, seperate inboxes, seperate outboxes,
95% seperation. My only point of contention is that they accounts share an
address book, and that I can live with. The seperate is so complete that if I
archive up the directory of one account, *nothing* breaks elsewhere. It
simply disappears. I do this to move mail from home to work and back, to have
an "archive" account, even to keep old accounts around with their complete
context intact.
Now, people have pointed out, rightfully, that this can me emulated,
nearly, with fetchmail/[filtering]/mutt. However, I do not consider this an
option for the average user. This is because nothing is really inhereted from
the account above. Everything needs to be defined on a folder by folder basis
and mutt simply is not up to the task visually. It's alert of *where* new
mail is is lacking. Filters for new mailing lists into new accounts need to
be created manually, etc. Great for the people who want to hack it together,
all the power to them, but it is not an option.
Now, please note, I am not saying that it doesn't work for people. I just
want it acknowledged by those people that it is *NOT* the same as what the
people are asking for, not by a long shot. If it works for you, fine, but
please don't say it is *THE* way to do things. It is not *THE* way, it is *A*
way.
I am also well aware of the power of fitting pieces together like
pipework. You can get from point A to point B. I wouldn't be in the position
I am now or hold the positions I have in the past (all SysAdmin related on
FreeBSD and Solaris boxes) without knowing the strengths of that. But it is
also from that viewpoint that I know the weaknesses. Like pipeworks, you can
get from point A to point B. However, if you need a complex system build out
of those pipes you soon end up with a rats nest of pipes and you're not sure
exactly where things are coming from and going to.
So while, IMHO, fetchmail/[filter]/mutt (or whatever) works well for a
single user who isn't too concerned about total seperation of accounts within
the application, it fails for those who want or need total seperation from
inside the application. I stress *inside the application* because one could
also simply have multiple accounts on a machine and SU between them. This is
not the same as sitting in a single application and doing the work.
Also, people have pointed out that it is a very Windows-esque way of
looking at things, a single monolithic application that does "Everything." I
don't see it that way. MUAs, on 'nix, are the only client/server application
which is not expected to handle its own connections and databases. A web
browser is responsible for retrieving and sending its own data to and from the
server. Same for FTP, telnet, etc, etc, etc.
Transport, at the MUA level, is talking to the appropriate POP/SMTP/IMAP
servers directly. Right now we need fetchmail to really handle multiple
accounts effectively.
Filtering is nothing more than handling the databases the MUA is using.
While I am aware of the strengths of procmail and exims filters, I do not feel
they should be the one and ONLY source of filtering. The MUA should be
responsible for filtering on its own criteria. I stress this because if an
MUA is going to handle transport from multiple POP servers, as it should, it
needs to be able to apply some filters to those messages. One can still have
server side filtering on those boxes, but those filters, in the pop sense,
fail since there is no way to access multiple boxes through POP.
Finally, handling multiple accounts in completely seperate environments is
also a requirement. Seperate inboxes, seperate outboxes, seperate filters,
seperate folders, seperate signatures, PGP keys, etc. The reason for this is
so that the user can simply and easily create subfolders and filters for one
account and have a LOT of things set by default. If they need to do something
differently, fine, give them the ability, but make the basic functions simple
*first*, not the complex simple and the simple complex.
For those who have read my rants before, you'll prolly get tired of
hearing this next part, but, here goes.
A perfect example of this is PMMail98 on OS/2 & Windows. Yeah, I know,
Windows, GUI, ick. But my point is not the GUI, not the mouse, not the
keyboard, not the look but the underlying logic of how it handles seperate
accounts as completely seperate entities within a single application.
As I write this I can see that in my personal account I have 1 new message
in Debial-Devel, 3 in Debian-Users, 290 in a Star Wars list that I have a
filter set up so that it won't alert me to new mail (haven't seen TPM yet,
don't want to read it). The rest of my folders don't have new mail. In my
work account I've got 4 new messages in my inbox and some new mail in my
"Mailing-lists" folder. I need to expand that branch to see which folders
have mail, though, but I know new mail is in that branch.
Each account has its own inbox, its own outbox, its own drafts folder, its
own filters, its own personalized settings. I want that seperation because
one *IS* my work account and one *IS* my personal account. I don't want to go
in and have to seperate out the sent-mail of one from the other. I don't want
to have to make filters seperate out the incoming mail. I don't want the
hassle of reseting my SMTP server so I *CAN* send mail from certain accounts.
I like having one account check mail every 30 seconds and one every 5 minutes.
I like having one account use joe as the editor, the other vim. I like having
perl as a tool I can use for my filters in one account and not have those same
filters hit another.
This is, to me, how mail has worked for the past 5+ years. This is an
utterly viable option and one that Unix is lacking.
Now, I may have been harsh when I said that Unix was "archaic" in its
thinking, but it is true, IMHO. What I keep hearing from people is that all
mail sent to a single location is, obviously, going to come back from a single
location. This is what I see in the fetchmail/[filter]/mail route and the
suggestion of using multiple application & | configurations to get the job
done in something approaching a reasonable answer.
Finally, yes, if I had the knowledge, expertise and time to code up such a
beasty I would. Believe me, I would! But I don't. I can code in perl but I
doubt anyone wants an ncurses, perl email client. Besides, I'm not that good
with perl in the first place. So the best I can do is point out that there
*IS* a deficiency, like it or not, and hope that someone with the talent and
time does hear and pick it up. I'll help them in any way I can.
Anyway, that is my peace, I'm done.
- --
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
- -------------------------------+---------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.0 (C) 1997 Pretty Good Privacy, Inc
iQA/AwUBN0dh2npf7K2LbpnFEQJr1wCgvmMZdKefFNze+WqepXfgxFQ0K50AnifT
csaTC2VzXfikAQVIx1TATw1Y
=tzOe
-----END PGP SIGNATURE-----
Reply to: