Hello Steve.
I didn't reply to this email because I opened the other thread on
dspam-devel, about that part of the code that looks for the double
newline after buf, and we've discussed that after this thread.
There was a time when I was getting the wrong message trained, that was
when I opened this thread.
Then I couldn't reproduce it anymore. The headers would just not be
parsed, or if they were, no action was being taken, and the message to
[email protected] would be delivered as a normal message, and bounced
(because [email protected] did not exist on the destination). It was having
erratic behaviour.
After ignoring that test (x>h) things just started working perfectly.
Another thing I just couldn't understand was, when using postfix aliases
and the custom pipe transport, as you posted here on 2009-07-02 with the
subject "Retraining Failing After Upgrade to 3.9.0-ALPHA2", how would it
work.
The problem is this:
message A: the original message that we want to retrain.
message B: the message that forwards message A.
1. postfix receives message B (to spam-...@xxx or s...@xxx)
2. message B is filtered normally and chances are high that it's
considered ham, because it's basically the same message as message A,
before that was delivered as ham.
3. message B is handed back to postfix
4. postfix via transport would hand the message B to dspam
5. dspam considers message B spam (was called with --class=spam)
6. message B is relearned.
What about the original false negative, message A?
Thank you for your time and support.
Carlo Rodrigues
Steve wrote:
Hello, all.
Hallo Carlos
I've been experimenting with retraining via email forwarding.
I have a 'shared,merged' group, of which [email protected] and
[email protected] are both members.
I receive message A, to [email protected], which is considered innocent,
then I forward it as an attachment to [email protected], because I
prefer the signature in the headers. Let's call message B to the message
that is sent with the message A attached.
When I check on the web-ui, I would expect to see message A marked as
Retrained, due to dspam retraining the tokens from message A, based on
the forwarded signature and no message B (B was the vehicle for
retraining). But what is happening is that message A is still untouched
and considered innocent, and message B is considered Spam, and gets
quarantined.
Is this the normal behavior?
The part that matters:
ParseToHeaders on
ChangeModeOnParse on
ChangeUserOnParse off
That is one part of the configuration. What about the part from the MTA? How
have you configured your MTA to pass that mail to DSPAM? Could you post that
part as well?
Regards,
Carlo Rodrigues
// Steve
------------------------------------------------------------------------------
_______________________________________________
Dspam-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-user
