Richard Freeman <[EMAIL PROTECTED]> wrote: > Elias Oltmanns wrote: >> >> 1. Specify the actual user instead of root on the commandline. >> > > Message successfully retrained > >> 2. Execute >> # /usr/bin/dspam --source=error --class=spam --user root >> --signature=1000,47601b27117601804284693 >> > > Message successfully retrained > > >> 3. The same with user instead of root. > > Message successfully retrained > >> >> 4. Add --mode=TEFT to the commandline options. > > When used with the failing commandline (--user=root, message content > piped in) it still doesn't work.
This strikes me as distinctly odd. I can't help but think that a bug somewhere in the code scanning messages for signatures may be the cause of your troubles. The tests have confirmed that your configuration is correct in so far as dspam does switch to the correct uid on retraining. The strange thing is that it can find the signature when parsing the message only if the matching user has been specified on the command line. Unfortunately, I really don't have the time to check the code myself and the fact that I suspect a bug clearly shows that I've run out of ideas. As for possible work arounds, I don't know how your users access your SMTP server. If you require authentication with per user credentials, your SMTP server knows who wants to retrain the message and can call dspam accordingly. As your tests have shown, dspam should be able to retrieve the signature then. [...] > I guess I can create a script that will pipe the message through formail > and extract the DSPAM signature header and then invoke #2 above. Before > I do that any ideas as to getting dspam to do this on its own? Well, actually it is meant to do this on its own. I really don't have the faintest idea why it does in one case and doesn't in the other. Regards, Elias
