[Dspam-devel] TrainPristine insufficient explanation in conf comments and debug logging

[<dsp...@li...>]

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=...`

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.

Would the sourceforge issue tracker, or a submitted patchset, be an
appropriate place to pursue this conversation?