[dspam-users] thanks for dspam, my experiences on FreeBSD, suggestions

[Ion-Mihai Tetcu]

[ as we're discussing more FreeBSD specific details, I've cc'ed
ports at FreeBSD.org if you feel this goes off-topic for dspam-users let's
follow up there ]

On Mon, 26 Apr 2004 08:21:08 +0200
Andreas Klemm <andreas at klemm.apsfilter.org> wrote:

> On Mon, Apr 26, 2004 at 12:44:11AM +0300, Ion-Mihai Tetcu wrote:
> > On Sun, 25 Apr 2004 13:57:58 +0200
> > Andreas Klemm <andreas at klemm.apsfilter.org> wrote:
> > 
> > > Hi Jonathan,
> > > 
> > > I'm very glad, that I selected your anti-spam package, it finally
> > > does everything I really need. Previously I used junkfilter, which
> > > on the long run had too many false positives for my taste.
> > > 
> > > After doing some training with it (~2000 spam mails and ~2000
> > > good mails) its really excellent in detecting spam.
> > > 
> > > It automatically sorts out about 50 mails per day which is
> > > definitively spam and has still 1-2 mails per day, where spam
> > > is still detected as innocent, well training goes on ;-)
> > 
> > Could you please take a look at:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=65384
> > and comment on it ?
> > Tnx.
> 
> At the first look I'd say, that its o.k. to offer more make control
> variables to have better control over what is compiled in.
> 
> I think some stuff from me has to be merged in.
> For example the location of the userdir ...

*I* would move debug logs and user dirs, but keep the config files in
${PREFIX}/etc/dspam.

I can make the patches, but I would be happy to receive some feedback
from rob, since he is the maintainer and he might have some plans on
this.
 
> I really dislike /usr/local/... for stuff that is really worth
> to keep ... and /usr/local sometimes relatively easy gets removed ...
> I like to keep sensitive/interesting data in /var ...
> 
> I'm not sure, if TUM mode should be enabled by default, since dspam
> is designed to start with 0 signatures ... But I don't know exactly
> what TUM is and what pros and cons it brings ...
> 
> Correct me if Im wrong, but ALT_BAYESIAN is enabled by default ?
> So am not sure if you really need it as option.

Uh, now it is, yes.

> > > In the attachement I prepared a patch for the FreeBSD port
> > > maintainer for review. It additionally contains some more
> > > variables to easily help you to compile in debugging and verbose
> > > debugging, what you will need for troubleshooting.
> > 
> > Perhaps you should be consistent with the naming scheme for the
> > knobs ? e.g. DSPAM_WITH_DEBUG --> WITH_DEBUG and make use of OPTIONS
> > ?
> 
> Well, its long ago that I looked into the porters guide ...
> I need a refresh here ...
> 
> Concerning variables like WITH_DEBUG...
> Im sure, that pretty many ports use WITH_DEBUG.
> What if I only wanna use WITH_DEBUG with one port ?
> 
> There can always show up similar/equal names ...

Well, one would only have problems if setting this in /etc/make.conf.
And you risk going this way, as various knobs don't generally contain
the port name.

But you can:

- after the first make config, if the port use ${DIALOG} (which is the
case) the options are saved in /var/db/ports/port_name/options and are
used on consequent builds (unless you do a make rmconfig; you can see
them with make show config; they are not removed by make clean)

- use portupade's pkgtools.conf

- use a Makefile.local in the port dir or a global one in ${PORTSDIR}

> I think a very good idea would be, to prepend the port name
> to every variable ...

If you really want that make an request on ports@; but I doubt you would
have great success because this would involve changes in a lot of ports
and would make the knobs longer.

> > > Suggestions
> > > ===========
> > > 
> > > 1) USERDIR location: for dspam and FreeBSD port
> > > ===============================================
> > > 
> > > I'd like to see the USERDIR per default somewhere under /var.
> > > I think a really good place would be /var/mail/dspam, so to say
> > > directly under the systems mailboxes.
> > > Reason, if you entirely want to get rid of all installed add on
> > > software by removing /usr/local recursively, then you also loose
> > > your spam databases.
> > > 
> > > 	--with-userdir=/var/mail/dspam
> > 
> > I'm strongly against this. The locations of configuration files for
> > ports is /us/local/etc/ More, having a /var/mail/dspam wouldn't be
> > very consistent with default mailbox delivery (if you happen to have
> > a dpsam user). However I also don't like having debug info, stats,
> > ... in etc/;
> > 
> > I could provide a patch for putting them into /var/log/dspam,
> > /var/db/dspam, etc.
> > 
> > What do you think ?
> 
> Yes ... the precious files  that make up a users dspam corpus
> should go to /var ...

Right. I've missed that in my PR, because I use mysql so I already have
my db in /var/db/mysql.
 
> And the config files should go to /usr/local/etc/dspam.
> 
> Debuging and logging should perhaps being done by syslog or
> by writing it into another suitable location.

/var/log/dspam/dspam.debug
/var/log/dspam/dspam.messages
/var/log/dspam/sql.errors

Is it OK ?

> Good would be an option, to get debug files by loginname ...

In newer versions of dspam you can do this.

> > > 2) README is missing some guidance for good working minimal
> > > installation
=====================================================
> > > 
> > > Whats good: very detailed migration hints, when having to do an
> > > update. I definitively will need this sooner or later.
> > 
> > Perhaps updating info should go into a separate file.
> 
> Maybe, because its a very large section ...
> 
> > > Whats odd: too much explanation, what might be done ...
> > > After reading all the possibilities of configure, I was confused,
> > > what I need for a good working installation for me.
> > 
> > Agree.
> >  
> > > One think was clear for me very soon, I definitively dont need
> > > a MySQL server with a spam database ;-)
> > 
> > Why ?
> 
> I dont want to have an additional service like an SQL database.
> I simply dont need that overhead.
> For my one user Unix Server/Workstation the db4 database is
> performant enough ...

Hm, I may be bias on this, as I really don't like db4. Jonathan is
currently working on a SQLite backend which will probably perform
better.

> Really dont want to have a "bloated" system with too many of
> applications ..
> KISS ... keep it simple and smart ... (thats the idea behind Unix ..)

Ja, ich weiss ;)

I use mysql because it performs better on with many users.


-- 
IOnut
Unregistered ;) FreeBSD "user"