Re: Q: List Policy
- To: email@example.com
- Subject: Re: Q: List Policy
- From: Henrique de Moraes Holschuh <firstname.lastname@example.org>
- Date: Tue, 2 Dec 2008 14:36:48 -0200
- Message-id: <[🔎] 20081202163648.GJ1668@khazad-dum.debian.net>
- In-reply-to: <email@example.com>
- References: <491F4761.firstname.lastname@example.org> <491F8FD1.email@example.com> <491F915E.firstname.lastname@example.org> <491FBDEC.email@example.com> <20081117100303.GD7280@localhost.localdomain> <4921607E.firstname.lastname@example.org> <20081121134551.GL3527@localhost.localdomain> <4927F088.email@example.com> <20081122121542.GA19745@khazad-dum.debian.net> <firstname.lastname@example.org>
On Sat, 22 Nov 2008, Ron Johnson wrote:
> On 11/22/08 06:15, Henrique de Moraes Holschuh wrote:
> I thought kernel hackers were uber-geeks. How can they not implement
> decent mail filtering? If you use Mutt, you take upon yourself the
> responsibility to set up a server-side filter, and if you use a GUI, then
> setting up client-side filtering is trivially easy.
That's an interesting question. I don't have any answers, but my best guess
is that, just like Debian will remain a no-CC zone, the Linux kernel MLs
have their own long-standing preferences. Like the "don't attach stuff,
send them in the main body" rule, which AFAIK mostly exists because of how
many popular MUAs used to behave (and I have no idea if they still do.
Mutt, which I use, does the right thing to in-line attachments).
I did not start in this thread with this opinion, but after reading it, it
was pretty clear to me that to-cc-or-not-cc really is just a preference
thing, like vi-or-emacs. Some of the reasons that make a person prefer one
over the other will be technical, but there are enough of them on both sides
to balance things out back into "it is just a matter of preference".
Like you can see in other replies to this thread, there are numerous
technical ways to make sure you will not miss a message (or have annoying
duplicates of it where you don't want them) with or without using Cc:. All
solutions for either case (including the one I described) depend on
cooperation from your MUA or mail filtering/delivery setup, which translates
to "not universionally available".
As for the kernel hackers being uber-geeks, well, even if they were (I bet
many aren't), this wouldn't make them uber-mail-geeks. There is a reason
why it was necessary to add a file in the Linux kernel Documentation/
directory about how to configure your MUA to not mangle in-line patches. I
believe there is an interesting field of study there.
> (Of course, even if you use a GUI, if you are a geek you should
> implement fetchmail/getmail, an MTA, a spam filter and procmail or
> mailfilter and IMAP, so that you can switch MUAs as easily as you switch
> underwear, or even access your mail from across the LAN or even Internet.
> But that's a different topic...)
As I said, not everyone thinks this is a worthy use of their time, even if
they have the skills to do it ;-)
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot