-----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-----