headers
Kevin A. McGrail | 1 Jun 2004 17:31
Favicon
Gravatar

Correction about Autolearn Headers

Many persons, including myself are interested in having the headers in a
MD+SA installation be as similar to SA's original headers as possible.

One of the differences I never solved was the autolearn status for Bayesian
tokens.  I was forwarded some code that originated on the SATalk email which
I unfortunately took on faith because it looked correct.

Unfortunately, after researching this further, it is my opinion that the
auto_learn_status is not available in the MimeDefang SubFilter and certainly
not through the SASpamTester Variable.  Whoever posted the original email on
SATalk had this completely wrong for a MIMEDefang installation.  It is
however, correct logic for the SA Learn status variable.

To go further, the SA Learn Status is a function of the SpamAssassin
PerMsgStatus that gets returned from a call to SpamAssassin's check()
function.

To clarify this in terms of MIMEDefang, the call to SA's check routine is
made in the subroutine spam_assassin_status and the status variable is
returned to spam_assassin_check where it is scoped locally AND finished
prior to executing sub spam_assassin_check.

Therefore, the only way to make this work that I can see is to modify
mimedefang.pl.  It would be a simple change to return $status, comment out
the $status->finish, and return $status to the subfilter where you would
need to run a $status->finish on it in the subfilter.  I will leave that to
Roaring Penguin to decide if they want to make that change.

Regards,
KAM
(Continue reading)

Permalink | Reply | 2 comments |
headers
David F. Skoll | 1 Jun 2004 18:13
Favicon

Re: Correction about Autolearn Headers

On Tue, 1 Jun 2004, Kevin A. McGrail wrote:

> Therefore, the only way to make this work that I can see is to modify
> mimedefang.pl.  It would be a simple change to return $status, comment out
> the $status->finish, and return $status to the subfilter where you would
> need to run a $status->finish on it in the subfilter.

You can do this already; just call spam_assassin_status from your
filter, and process the status object yourself.  Heck, it's even
documented in the mimedefang-filter man page. :-)

Regards,

David.
Permalink | Reply | 1 comment |
headers
Kelson Vibber | 1 Jun 2004 18:44
Favicon

Re: Correction about Autolearn Headers

At 09:13 AM 6/1/2004, David F. Skoll wrote:
>On Tue, 1 Jun 2004, Kevin A. McGrail wrote:
> > Therefore, the only way to make this work that I can see is to modify
> > mimedefang.pl.  It would be a simple change to return $status, comment out
> > the $status->finish, and return $status to the subfilter where you would
> > need to run a $status->finish on it in the subfilter.
>
>You can do this already; just call spam_assassin_status from your
>filter, and process the status object yourself.  Heck, it's even
>documented in the mimedefang-filter man page. :-)

This was possible in SA 2.5x - however, beginning with 2.60, the 
SpamAssassin object no longer exposes the auto-learn results or the 
function to build the status line.  (It didn't technically expose either 
before, but you could get the status line through an undocumented function 
-- which no longer exists.)  You can construct it from all the other 
pieces, but auto-learn isn't available.

Kelson Vibber
SpeedGate Communications <www.speed.net>
Permalink | Reply | 1 comment |
headers
Kevin A. McGrail | 1 Jun 2004 19:10
Favicon
Gravatar

Re: Correction about Autolearn Headers

Gotcha.  Forest for the trees.  The wasted time from someone posting
supposedly working code getting the auto_learn_status from $SASpamTester had
me going 180 degrees the wrong way.

> You can do this already; just call spam_assassin_status from your
> filter, and process the status object yourself.  Heck, it's even
> documented in the mimedefang-filter man page. :-)
Permalink | Reply | 0 comments |
headers
Kevin A. McGrail | 1 Jun 2004 19:48
Favicon
Gravatar

Re: Correction about Autolearn Headers

Kelson,

I've looked at the 2.63 source code and MD 2.42 source about this and I
think the auto_learn information *is* available though not documented.

The changes I think are required are basically this:

1. do not use the spam_assassin_check built into MD.
2. make your own spam_assassin_check that checks the permsgstatus object and
builds the autolearn information

here's my first (untested) pass at the problem
(http://www.peregrinehw.com/downloads/MIMEDefang/contrib/autolearn_info):

sub my_spam_assassin_check (;$) {

    my($status) = spam_assassin_status( <at> _);
    return undef if (!defined($status));

    my $hits = $status->get_hits;
    my $req = $status->get_required_hits();
    my $tests = $status->get_names_of_tests_hit();
    my $report = $status->get_report();
    my $autolearn = "";

    #Check if Bayesian is Turned On, If AutoTesting is Turned On, or if
AutoLearning is turned off
    #I believe $SASpamTester will have this info and will be in scope if
called from filter_end.
    if (($SASpamTester->{conf}->{bayes_auto_learn}) and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Penkower | 2 Jun 2004 15:05

Help with Spamassassin

I am about to set up Spamassassin

I do not plan on doing anything sophisticated with it. I don't want to
use any point based system.  I simply want to define a list of banned
words in the body.  If any of these words are present, bounce the email.

Can somebody please direct me to the appropriate SpamAssassin
configuration file and post a sample config file to do this.

Thank you.

Mark Penkower
Permalink | Reply | 4 comments |
headers
Graham Dunn | 2 Jun 2004 15:53

Selectively blocking .zip files

We send and receive a fair amount of .zip file containing file types in
the $bad_exts category. As such, I'm trying to come up with a simple
method to allow certain zip files through, while excluding the nasty
ones.

The first shot I've taken at this is getting people to add a prefix onto
their zip attachment (supersecretword in the example). It's sort of
cludgy, but is very simple to communicate and doesn't change the
workflow.

Does anyone have ideas about potential problems with this?

# This procedure returns true for entities with bad filenames.
sub filter_bad_filename ($) {
    my($entity) =  <at> _;
    my($bad_exts, $re, $secret);

    # Tacking this on to the start of the zip name will let it through
    $secret = 'supersecretword';

    # Bad extensions
    $bad_exts = '(ade|adp|app|asd|asf|asx|bas|bat|chm|cmd|com|cpl|crt|dll|exe|fx
p|hlp|hta|hto|inf|isp|jse?|lib|lnk|mdb|mde|msc|msi|msp|mst|ocx|pcd|pif|prg|reg|s
cr|sct|sh|shb|shs|sys|vb|vbe|vbs|vxd|wmd|wms|wmz|wsc|wsf|wsh|\{)';

    # Do not allow:
    # - CLSIDs  {foobarbaz}
    # - bad extensions (possibly with trailing dots) at end
    $re = '\.' . $bad_exts . '\.*$';
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonas Eckerman | 2 Jun 2004 16:07

Re: Help with Spamassassin

On Wed, 2 Jun 2004 09:05:12 -0400, Mark Penkower wrote:

>  I am about to set up Spamassassin

>  I do not plan on doing anything sophisticated with it. I don't
>  want to use any point based system.

Well... The whole point of SpamAssassin is the point based system. If you're not going to use what
SpamAssassin is made for, I think using SpamAssassin would be incredibly overkill.

> I simply want to define a list of banned words in the body.
> If any of these words are present, bounce the email.

As you're not going to use the main features of SpamAssassin anyway, I'd suggest you simply implement this
check directly in mimedefang-filter instead. Using SpamAssassin for this will just result in a *lot* of
otherwise avoidable overhead.

Regards
/Jonas

--

-- 
Jonas Eckerman, jonas_lists <at> frukt.org
http://www.fsdb.org/
Permalink | Reply | 2 comments |
headers
Jim McCullars | 2 Jun 2004 16:06
Favicon

Re: Help with Spamassassin


On Wed, 2 Jun 2004, Mark Penkower wrote:

> I do not plan on doing anything sophisticated with it. I don't want to
> use any point based system.  I simply want to define a list of banned
> words in the body.  If any of these words are present, bounce the email.

   There are two things you will need to do.  One, define the rules in
your local SpamAssassin config (the location depends on your installation,
but if you will look at the mimedefang-filter man page, it will show where
MIMEDefang thinks it should be); and two, update your MD filter to detect
that your local rule was triggered and bounce the email.

   For the first part, put something like this in your local SA config
file that MD uses:

body LOCAL_BANNED_WORD /\b(?:word1|word2|word3|word4|word5)\b/i
describe LOCAL_BANNED_WORD Words that should not appear in any email
score LOCAL_BANNED_WORD .01

   For the second part, look in the sample filter file that comes with MD.
In the filter_end() subroutine, take the part that looks like this:

    if ($Features{"SpamAssassin"}) {
        if (-s "./INPUTMSG" < 100*1024) {
            # Only scan messages smaller than 100kB.  Larger messages
            # are extremely unlikely to be spam, and SpamAssassin is
            # dreadfully slow on very large messages.
            my($hits, $req, $names, $report) = spam_assassin_check();
            if ($hits >= $req) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin A. McGrail | 2 Jun 2004 17:30
Favicon
Gravatar

Re: Help with Spamassassin

> > I simply want to define a list of banned words in the body.
> > If any of these words are present, bounce the email.

Bouncing emails based on words in the content is doomed to failure.
Incidents involving things like a persons last name of Handcock or Dick
Nixon or Shitake or numerous other valid uses of foul language will become
more apparent to you immediately.

Regards,
KAM
Permalink | Reply | 1 comment |

Gmane