Re: OT: why I don't want CCs
Jesse Meyer <meyer@btinet.net> 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
Reply to: