The Answer Gang

We have guidelines for asking and answering questions. Linux questions only, please.
We make no guarantees about answers, but you can be anonymous on request.See also: The Answer Gang's
Knowledge Base
and the LGSearch Engine

Greetings from Heather Stern

Greetings, folks, and welcome to the world of The Answer Gang. It's
been a fine time getting up to speed in our new digs, but now I'm
indulging in some spring cleaning.

Taking a look at my hard disk I'm way overdue, too. Let me see...
multiple chroot environments being used as development areas, some of
which distros aren't even supported by their own vendors anymore.
Rescue a few bits of actual code trees, then tarball these things off to
a CD, Poof! Hey, that's not too bad. What else can I toast here?
(BTW, has the state of the art in DVD burning gotten anywhere close to
"just buy one at the computer store and Linux will deal with it" quite
yet? I've been too lazy to check.) Some stray PDFs while I was
planning my kitchen remodel... from years ago. I haven't even started
thinking about cycling off backup tarballs yet.

Then there's mail cleanup. I've got quite an email humor collection. There
ought to be lots of dupes in that, but it'll be amusing reading all
through the summer to clear my way past it all, deleting attached pics
that aren't funny, and making a little gallery of ones that are. (There
are oodles of gallery software available on Freshmeat, but I probably
won't make it public; my bandwidth isn't up to that.) While not a
direct relation to how much disk space I'm eating, some serious antispam
principles could at least do spring cleaning on my available time.
Jim's been thinking of instituting greylisting on our mail server.

Now I have to note the term is a mite overloaded. I mean, we've been
talking about whitelists (our good friends) and blacklists (mail never to
be seen again, whether you use the RBL/MAPS servers and their kindred or
not) but grey, what's that? The fact is that just seeing your friend's
raw address isn't nearly enough; viruses steal names out of address
books freely to spoof headers. Clued people like me can add header
checks to spot they are really coming from their expected route or mail
agent ... but those can change and when they do, your friends will be
out of contact. Ouch. Also, mailing lists that are very open (hmm, do
I know any of those? *wink*) are often targeted by spammers who
hope their mail will hit many at once, while their traces are hidden by
standard list-header mangling. The fact is that even the good guys need
a little checking, and anyone who needs to receive mail from
completely unknown people has to do something serious. Separating off
how much checking to really do reduces CPU load for some cases, but that
is where it gets a bit greyer. There's ASK and TMDA for making new folk
at least reply before you'll talk to them. This greylisting practice is
pleasantly sneaky, doing something similar but at the transport layer.
Systems run by real people sending real messages really have to have
mechanisms for trying again if a server's too busy, a little overloaded,
maybe drop back and visit the secondary MX. But spammers don't have
time to waste on all that - they've umpty squadzillions other suckers
to mail. So greylisting responds with a temporary error condition, but
logs who came by; at some vaguely random later point but within popular
and reasonable human timeouts it will accept the mail from that server
knowing it's a repeat call... and the chances that it's someone utterly
normal increase drastically. And even the spammers who follow normal
protocol will be stuck hosting their own stupid mail during the delay,
costing them resources instead of legitimate ISPs. The downside
is not really getting instantaneous notes from your correspondents,
but I'm sure this can be tuned a bit.

Of course, you could always just take the classic techie's option - get
a bigger hard disk. With all that I'm up to in my development and
experimenting, it looks like I'll have to do that. Hah. Watch me
complain, twist my arm
Now I should really figure out about backing up this stuff in a way that
would be easy to restore if I have a problem... um, on something that
doesn't take more space than the original does. Otherwise trying to
clean up the house in general will have us wondering where to put all
this. Gosh, laptop drives are getting better capacities these days.
Much easier than dealing with tapes and discs, a mere 4G per disc
disappears pretty quickly nowadays, worse if you're sticking with CDs.

I'm about to attend a music convention; my crew's running an Internet
Lounge at Consonance. So all
the older systems in miscellaneous condition are being brought up to
speed and truly dead parts are finally being tossed. Wow. I'm starting
to have shelf space in my hardware cabinet again. That's more like it.

And of course, I've improved the preprocessing scripts I use to match
the new stuff we have going on here. So I'm pleased to reintroduce the
TAG in threaded form. Thomas did nearly all the work marking it up (for
which we can thank his Ruby scripting talents) but the layout tricks are
still mine. Let us know if you find any dust that still needs cleaning
out of 'em. Have a great month, folks.

Readers with good Linux answers of their own, in local mailing
lists or published to netnews groups are encouraged to copy The Answer
Gang their good bits if they're inclined to see their good thoughts
preserved in the Linux Documentation Project, by way of the Linux
Gazette. Ideally the answers explain why things work in a friendly
manner and with some enthusiasm, thus Making Linux Just A Little
More Fun! If they're short and sweet they'll be in Tips, longer
ones may be pubbed here in TAG. But we don't promise that we can
publish everything, just like we don't promise that we can answer
everyone. And last but not least - you can be anonymous if you'd prefer,
just tell us when you write in.