some even enjoying the chance - to hit a few potholes now and then. Open
     source gives us that choice.
            ____________________________________________________

LG#105, "Fine-tuning SpamAssassin"

   Sat, 16 Oct 2004 12:31:26 -0400
   Ben Okopnik ([35]ben from linuxgazette.net)

   In spite of my recent hardware problems, there's been a very pleasant and
   positive change in my computing experience over the past few months; namely,
   the  amount of spam that I have to "handle" (i.e., false positives and
   negatives) has gone to nearly zero. I wanted to mention it here, since
   Neil's article was responsible for getting me started down this path.

   Here's the snapshot of what it took:

     1. Followed the recommendations in the article, all except DNS blocklists.
     Biggest surprise: the amount I could reduce the spam point threshold
     (currently at 3.0) without any resulting false positives. I could probably
     go even lower...

   2. Training the Bayesian filter on the odd false negatives became trivial
   once I set up the Mutt macros:

     macro index \eb "|sa-learn --spam^M" macro pager \eb "|sa-learn --spam^M"

   Other than that, I've built up its database by dumping my spambox into it
   when it exceeds 100 emails:

     sa-learn --spam --mbox /var/mail/spam

   3. Whitelisted those of my friends who routinely BCC mails to me.

   As a result of all of the above, plus a very simple procmail recipe - other
   than basic sorting into my various mailboxes, it considers as spam anything
   that is not sent to one of my valid addresses - the last 1000 emails have
   resulted in 0 false positives and 2 false negatives. Given that 57%+ of the
   total (so says a quick analysis of my /var/log/procmail) was spam, those are
   pretty impressive results.

   Thanks for the initial push, Neil!

     [Neil] I'm pleased to have been some help.

     A couple of things I've learnt since I posted the article.

     SpamAssassin has a maximum database size and frequently expires tokens in
     the database, so the database won't grow too large. this size can be tuned
     with the bayes_expiry_max_db_size setting in the configuration. The value
     seems to be the number of tokens, rather a size in bytes.

     If you've misclassified something and you need to relearn it there's no
     need to use sa-learn --forget. If you've classified ham as spam, sa-learn
     --spam will automatically forget the learning as ham when told to learn it
     as spam and vice-versa.

     [Mike] Good to know, I've been meaning to look at SA's scoring more
     closely.

     My ISP recently went to rejecting mail with more than fifty recipients in
     the  headers, and that alone cut down my spam by 75%. They also use
     Postini, but there was a huge shrinkage in my Postini spambox after they
     did this. As in, down from a thousand messages a month to fifty.
            ____________________________________________________

Re: How to Reset forgotten Root passwords

   Fri, 22 Oct 2004 21:18:07 -0400
   Suramya Tomar ([36]LG Article Author)
   Additional Info from Ihar 'Philips' Filipau (filia from softhome.net)

   Got  this email from Philips with some additional information about my
   article in LG 107 on how to reset root passwords. He talks about a special
   case where the process I described wouldn't work.

   He has graciously give me permission to share this with you and since I
   think you might find this interesting I am cc'ing this to the TAG.

   What do you think, would it be too hard to reset passwords on SELinux?

   - Suramya

     [Ben] Nope. Just as you would pass "init=/bin/bash" or whatever on the
     command line, you could pass "selinux=0" to completely disable the SELinux
     features. You said it in your article: "physical access equals root
     access."

     Sure, there are things you can do that would definitely prevent somebody
     from modifying your /etc/shadow - a large rusty axe vigorously applied to
     the hard drive comes to mind (encrypting the entire HD would be a close
     modern equivalent) - but we're talking about very rare exceptions. People
     who run specialized secured systems but haven't built up a kit of tools to
     take care of the now-different set of problems have only themselves to
     blame, while the rest of us laugh at them.

   Thing here, it wasn't something specialized, but rather normal setup of
   Fedora Core 2. 

   People didn't knew a thing about SELinux, besides /promotion/ on RH site