ending the spam.assassin.prefs.conf madness.

[Rick Cooper]

    [ The following text is in the "iso-8859-1" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]

> -----Original Message-----
> From: MailScanner mailing list [mailto:MAILSCANNER at JISCMAIL.AC.UK]On
> Behalf Of Matt Kettler
> Sent: Monday, November 21, 2005 8:35 PM
> To: MAILSCANNER at JISCMAIL.AC.UK
> Subject: Re: ending the spam.assassin.prefs.conf madness.
>
>
[..]
> That much I understand.. the part I did not understand is if this
> code is in
> Mail::SpamAssassin::init() does siterules become an accessible member of a
> Mail::SpamAssassin object or not.
>
> I've never got the hang of figuring out how to tell what variables are
> externally accessible and which are not in perl code. As a C++
> programmer it all
> looks rather haphazard with no clear way of identifying
> interfaces, except that
> which is documented separately in man pages. But then again, I
> don't know the
> language, so that appearance my just come from lack of good understanding.
>
>  For example, as said previously, I have no clue why the "my"
> does. I assume it
> has something to do with scope, but does it make it the
> equivalent of "private"
> (ie: my = mine and mine alone) or "public" (my = my exported member)?

Well it has been said that perl is write a write only language. I have been
bit by the "my" critter more than once.
"my" does set the scope depending on where it is. It can be as local as a
loop/control structure. The thing I hate about perl is the method of passing
variables to a sub, and of course the "magic" undeclared default var with no
name.
"my" is local to the structure it's declared within. Make the mistake of
declaring a var with "my" inside a looping structure and drive your self
crazy trying to figure out why the variable is empty when you exit the loop.

I suppose one could parse through the code to figure out where the $self
referenced in the code fragment you posted came from. It would seem, at
first glance

    my $siterules = $self->{site_rules_filename};
    $siterules ||= $self->first_existing_path (@site_rules_path);

that the same method of access would probably work. If the
site_rules_filename property of the object is empty (and that would be a
value passed by MailScanner in the first place) then
$object->first_existing_path(@site_rules_path); should return the path...
IIRC @site_rules_path is global. If it's not it could certainly be created
with the same information that I posted from the SpamAssassin.pm code
defining @site_rules_path, in fact I believe that information was in the
readme also.


>
>
> > So if you were to use the attached revision of the script I
> posted earlier
> > it will look in all the possible dirs except /opt/$DIR or $DIR
> (no way to
> > tell what $DIR is).
>
> That much I understand too. I was hoping to find a good way to
> extract this
> information directly from a small perl script invoking a
> Mail::SpamAssassin
> object. This way you'd be able to identify it with 100% accuracy,
> and would keep
> abreast of changes in the SA code.

If I get the time tomorrow I will try the method I mentioned above.

> I agree wholeheartedly. My actual complaint is that the existing
> spam.assassin.pref.conf creates several pitfalls for novice users
> to fall in.
> Something which is clearly bad for novices if we want to help them.
>
> I'm a relatively knowing user and have fallen into many of these
> traps myself.
> This implies very bad things are ahead for the novice.

This part I will bow out on this part. I have nothing like a stock
spamassassin.prefs.conf and when I build the MailScanner installations for
my various servers I have my own install script because of site specific
items that have to be changed depending on the server it installing on, my
own patches to MailScanner and such that the standard installation methods
are useless to me. I think it's great, however, for most/many admins and
certainly for novices.


[..]

Rick


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

------------------------ MailScanner list ------------------------
To unsubscribe, email jiscmail at jiscmail.ac.uk with the words:
'leave mailscanner' in the body of the email.
Before posting, read the Wiki (http://wiki.mailscanner.info/) and
the archives (http://www.jiscmail.ac.uk/lists/mailscanner.html).

Support MailScanner development - buy the book off the website!