Re: [Dspam-devel] TrainPristine insufficient explanation in conf comments and debug logging
Brought to you by:
paulcockings,
sbajic
From: <dsp...@li...> - 2014-11-22 11:00:06
|
What are the skills required to take on maintenance? I have done a bit of C and perl coding and I've used dspam in the past. I would like to use it again. Off course, I really never tried to grasp a code base as big s dspam... But somehow, I feel tempted. And I was really happy when I used it years ago. It is really a shame it came to this point... -----Original Message----- From: dsp...@li... Date: Sat, 22 Nov 2014 03:00:13 To: <dsp...@li...> Reply-To: dsp...@li... Subject: Re: [Dspam-devel] TrainPristine insufficient explanation in conf comments and debug logging Le 2014-11-21 17:03, dsp...@li... 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 ------------------------------------------------------------------------------ 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 Dsp...@li... https://lists.sourceforge.net/lists/listinfo/dspam-devel |