Re: wallowing out of the spam quagmire

[Harry Putnam <reader@newsguy.com>]

Jonas Steverud <tvrud@bredband.net> writes:

> Harry Putnam <reader@newsguy.com> writes:
>
>> Listening to various posts on that it seems have all the earmarks of
>> being a pain in the butt.
>
> Both yes and no. The problem is to understand how spam.el works. It is
> not complex, the documentation is simply not yet complete. Read it
> before you continue with this email.

I'm not sure we're from the same planetary system... or as bare
minimum you must have a rather bizarre notion of what `not complex'
means.  I went glassy eyed after the first couple hundred lines.

I'm introduced to black lists, black holes, hash-cash payments,
bogofilters, on line data bases, bbdb as white list, some absolutely
convoluted processing that seem to require `split fancy' which I've
never used.  Some use of gnus registry, which I also have never messed
with.  Many lines of variable discussion which apparently is supposed
to spell out what 2780 lines of elisp in spame.el do.

In my world, this is quite `complex'.
>
>>    1) procmail/SpamAssassin based pre filtering (before gnus)
>
> I assume it places all spam in a specific group, lets for the
> discussion call it nnfolder:Spam.

No, but sort of similar.  I used plain splitting inside gnus for a few
years but gave it up a couple years ago in favor of procmail.  For
some time now I've left all splitting to procmail/SpamAssassin.  What
gets past procmail/sa ends up in a single inbox where I deal with all
of it by hand.  That inbox is getting an increasing amount of spam.
Stuff that is hard to indentify etc.

So to summarize.  I let procmail/sa do most splitting and culling out
of spam.  When that is done, the rest comes to my inbox and I deal
with it by hand.  I hoped to introduce bogofilter at that stage.

Many thanks for posting your setup... However it seems fantastically
complicated to me.

I had visions of leaving all spam that spamassasin and procmail find
out of the equation.  Then whatever gets to my single inbox, I had
visions of marking any spam as such and moving it to a spam group.
Maybe copy ham to a ham group.  Then let these messages be the
training tools for bogofilter.  After showing bogofilter enough
examples isn't is supposed to take it from there?

As training begins I'd introduce splitting into my single inbox as
the tools learn what is what.

I'm not sure what this training actually does in practice, but it
sounds like bogofilter begins to know what is spam.  If so, then I'd
tell bogofilter to remove what it thinks is spam. No other splitting
would be needed.

Not at all clear why a fancy-spit is required to do that.  In fact
its kind of hard to imagine a spit rule at all.

Seems like one would just invoke bogofilter on each message and send
each one to spam or ham.  Technically a split, I guess but not very
complicated. The complicated part seems to be what goes on inside
bogofilter.  The messages it will be seeing have already skirted SA's
complex set of interrelated rules, plus my own homeboy procmail rules
and tweaks to SA.  So this mail will be hard to find a pattern or some
other thing to help indentify it.

The above semi-diagram seems fairly simple to me.  But I don't see
how it can be done with the current documentation. I have no idea how
to implement this.

I've probably talked myself right into a hole but how can I set up
the simple system described above?

Have I over looked step by step instructions?  I'm assuming by
documentation people mean the stuff at:
  Filtering Spam Using The Spam ELisp Package
I haven't found a step by step there.

I guess ...Spam ELisp Package Sequence of Events
is as close as it gets..  Sounds like I need the auto-detect method
and would set G p on my single inbox group to something that tells
spam.el to `auto-detect' in it.

My case should be the simplest possible example of using spam.el and
bogofilter, but I'm not sure about involving gnus registry etc.
Or what `exactly' needs doing.

I'm going to look for Teds patch to docs right now.