[TAG] need information about sylpheed-claws

[Benjamin A. Okopnik]

On Tue, Apr 12, 2005 at 12:41:21AM +0200, Karl-Heinz Herrmann wrote:
> On Thu, 7 Jul 2005 21:18:06 -0400
> "Benjamin A. Okopnik" <ben at linuxgazette.net> wrote:
> 
> > ben at Fenrir:/tmp$ dd if=/dev/zero bs=1GB count=1|bzip2 > foo.bz2
> > -rw-r--r--  1 ben ben 722 2005-07-07 21:05 foo.bz2
> > ben at Fenrir:/tmp$ mutt -s 'Hi, Karl-Heinz!' -a foo.bz2 kh at somewhere.com
>  
> > If you project that kind of compression ratio to, say, 1TB or so, you
> > can see how it might fry an AV utility's little brain... and if Mr.
> > Cracker is lucky, it might totally fill up the partition as well.
> 
> That would indeed be a nasty mail bomb. On the other hand I felt rather
> save from viruses on a Dec alpha/64 bit running OSF Unix which was even
> hidden behind a firewall and did not receive mails directly.

...which is, of course, The Right Thing in many cases.

                __ Mail server __
--> Router/FW <                   > Router/FW --> LAN
                -- Web server ---

Both of the servers, of course, have a minimal tool set (just enough to
accomplish the job they need to do) so that Mr. Cracker has nothing to
work with if he should get that far... so cracking the outside router
AND root on the servers that have a public "face" leaves him essentially
where he was before he started - or worse. Better yet, use Kapil's
"transparent FS" idea: the reads go through to the FS, but the writes to
everything except, e.g., the mail spool and the logs go off to
/dev/null... let'em figure *that* one out. :)

> Still for the querent I think the best is to to decouple the
> gui-mailer and the filtering to avoid long waits and hangs. Then
> spamd/spamc should do nicely even on a rather meager system. I did not
> get the impression that fetchmail was exceptionally memory hungry, just
> CPU spikes. 

[Nod] That's my experience as well. It seems to me that anytime you can
use an "older", console-based Unix utility or an older, time-tested
daemon, you're better off in terms of resiliency and broader
capabilities; certainly in regard to the range of things that can be
handled without bogging the system.

I use GUIs the way some people make sushi: the stuff on top is just
*flavoring*, not the actual food (the /gohan/ is what holds that
distinction <http://www.japan-guide.com/e/e2043.html>). And I agree with
Brian: a mouse is indeed a device for selecting which xterm you type in.
Except I usually use the Alt-Tab key. :)


* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://linuxgazette.net *