On Sat, Nov 22, 2014 at 03:00:13AM +0000, dspam-devel@lists.sourceforge.net
wrote:
> Le 2014-11-21 17:03, dspam-devel@lists.sourceforge.net a écrit :
> > src/dspam.conf.in:
> > # TrainPristine: for systems where the original message remains
> > server side
> > # and can therefore be presented in pristine format for retraining.
> > This option
> > # will cause DSPAM to cease all writing of signatures and DSPAM
> > headers to the
> > # message, and deliver the message in as pristine format as possible.
> > This mode
> > # REQUIRES that the original message in its pristine format (as of
> > delivery)
> > # be presented for retraining, as in the case of webmail, imap, or
> > other
> > # applications where the message is actually kept server-side during
> > reading,
> > # and is preserved. DO NOT use this switch unless the original
> > message can be
> > # presented for retraining with the ORIGINAL HEADERS and NO
> > MODIFICATIONS.
> > #
> > # NOTE: You can't use this setting with dspam_trian; if you're going
> > to use it,
> > # wait until after you train any corpora.
> > #
> > #TrainPristine on
> >
> > This option caused me some significant headaches recently. My
> > travails
> > are partially documented on the dspam-user mailing list. I come to
> > you, dspam-devel, to request that the documentation here be improved.
> > In particular, the note in these comments mentions dspam_train, but
> > it
> > does not mention that using this option will also break
> > reclassification through the web frontend along with any other tools
> > that try to use `dspam --signature=...`
>
> Indeed. It could be a bit more exhaustive.
>
> >
> > Additionally...
> >
> > src/dspam.c:
> > LOGDEBUG ("saving signature as %s", ATX->signature);
> >
> > if (CTX->classification == DSR_NONE && CTX->training_mode !=
> > DST_NOTRAIN)
> > {
> > if (!ATX->train_pristine) {
> > int x = _ds_set_signature (CTX, CTX->signature,
> > ATX->signature);
> > if (x) {
> > LOG(LOG_WARNING, "_ds_set_signature() failed with error
> > %d", x);
> > }
> > }
> > }
> >
> > The LOGDEBUG message here is very misleading since the signature
> > doesn't actually get saved all the time. Those three conditions can
> > prevent saving of the signature. There should probably be two
> > separate
> > LOGDEBUG here, the second one inside the conditionals.
>
> True again.
>
> >
> > Would the sourceforge issue tracker, or a submitted patchset, be an
> > appropriate place to pursue this conversation?
>
> There is nobody maintaining dspam anymore, so nobody to merge, less
> write, a patch. But if you feel like taking on the maintainance
> altogether then please be my guest, you'd make many people happy.
>
> Best regards,
>
> Thomas
>
I would be interested in helping to keep it up to date. What do I need
to do to get access to make update to the source code repository? Currently,
I just make all our fixes to local copies.
Regards,
Ken
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel
