Jesse Meyer <[EMAIL PROTECTED]> writes: > I also find that a local MTA on a laptop is great. I have a local > network which grabs my email from several sources and sorts it, then > every other machine on the network can access that email via imaps. > > My laptop is configured to periodically check to see if it can make > a connection to the server, and, if it can, synchronize the laptop's mail > directories with the servers (offlineimap). > > The end result is that I can take my laptop anywhere, read the messages > that it grabbed from the server, compose my replies, all without > worrying what network connectivity I have. Once I get home, I just need > to plug the laptop into the local network: no logging in or running a > specific program.
Ok so I was very wrong about this. I think this is very useful. What I meant is that if I go on the road with my laptop, I can connect to a net connection there and use the smtp server of the ISP there. With mozilla all I have to edit is one field (the outgoing mail server), I don't have to wait until I get home. With mutt I have to change some setting in my MTA, which I'd rather not mess with. > This collection of several binaries (exim, procmail, courierimap-ssl, > bogofilter, fetchmail, offlineimap, mutt, vim, gnupg, etc) may seem like > a massive PITA just to read and reply to email, and it is harder to > setup then opening Outlook Express, pointing it to a smtp and pop3 > server, and entering in a few lines of information. In exchange for the > initial difficulty, I gain a modular system that is easy to maintain, > upgrade, and adapt to my needs. I don't have to find the one true email > client that does all of the above - instead, I can mix and match the > best of breed in each category. I don't have to have to use the email > client that has a poor mail editor just to get a good spam filter: I > can continue to use mutt and vim with bogofilter. Perhaps one day > I'll decide that spamassassin is a lot better then bogofilter, and > switch - but if I do, I don't need to learn anything else: any unix > email client should work with it. I can jump from mutt to emacs and my > mail sorting and spam filtering will still work. This argument just doesn't make it. Mutt does filtering (shouldn't procmail be doing this). Mutt does IMAP and POP (shouldn't fetchmail and offlineimap do this). Mutt does encryption (ok so it probably runs gnupg in the background but still this means you can't use GENERICpg because it might not use exactly the same options). With all of those things you have an option of running an external program or using the built-in support of mutt. Sadly for me, I use external programs (fetchmail, procmail, spamassassin, and so on) for getting mail, but I would like mutt to handle just sending the mail. But for some reason only that part of the chain is taboo. > From the end user perspective, the above might be a bogus argument - > how many people truly change their email client from day to day? From a > development perspective, the modularity looks a lot different - I don't > have to trust the mutt developers to be experts in encryption - that's > the gnupg team's responsibility. The exim guys don't need to worry > about how to inject email from remote systems and deliver it locally - > the fetchmail group has already written a program to grab the email, > rewrite the headers, and feed it to exim for local delivery. For a > developer, the code becomes simpler, yet, with all the apps taken as a > whole, the end result can have many more features then the typical > windows mail client. At the same time, by delegating different tasks to > different programs, there is less duplication of effort, and the results > are available to everyone. If gnupg adds a new feature, or better > optimization, elm and mutt users benefit. Mutt doesn't need to add > an editor to itself - it can use vim, and vim doesn't need to add a > spellcheck - its simple to find the plugin that uses ispell or aspell to > do the job. > > Unix application modularity may have an abstract elegance, but it also > tends to lead to "smarter" program chains then having one large program. > Coders don't have to be experts in every aspect of a task - all > they need to know is how to write their code so that other modular > programs (whose coders are experts on that specific task) can work with > their own. There are two philosophies. One thinks that dealing with email is one task. And therefore requires one program. The other thinks that receiving mail, filtering mail, reading mail, replying to mail, sending out the replies, and so on, are each seperate tasks. In the end I don't care at all which of the approaches a piece of software takes as long as it works. However I find it odd that mutt receives mail (POP and IMAP), mutt filters mail, mutt shows summary of mail, mutt reads mail, but mutt doesn't send mail. If one wanted to be crazy about unix philosophy one would remove POP and IMAP, and remove filtering. Even the displaying of messages should have been passed on to less or more (I know mutt has it's own pager, but by unix logic it doesn't need it, just as it doesn't need an editor like pine's pico :). I also find it weird that Evolution is a kitchen sink (Microsoft Outlook) type email client, but it support local mbox and maildir, external gpg, external spamassassin, internal and external filtering, and sending through local MTA or through smtp smarthost. However I don't think it supports an external editor, although it might. > Going back to the end user, we find another bonus - no longer does the > end user need to learn how to do the same task different ways - if the > program is going to need an editor, it can use the editor the end user > is most comfortable with. Any tricks I learn in vim I can use while > composing messages in mutt or slrn. Pine comes with pico, but you can use vim instead. Mutt supports IMAP and POP but you can use external apps as well. Evolution can use SMTP smarthost or local MTA. In each of these cases the advanced user can choose to ignore the built-in functionality. > Which is why I like Unix/Linux. One reason why I do is choice. That's why I don't like software that says: "You can't do X this way", even though *I* want to do it that way. Bijan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
