Bug Tracker item #3141675, was opened at 2010-12-22 13:03
Message generated for change (Comment added) made by unwesen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3141675&group_id=250683

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: daemon
Group: v3.9.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jens Finkhaeuser (unwesen)
Assigned to: Stevan Bajic (sbajic)
Summary: Unlearning a message is broken

Initial Comment:
I've been trying to figure out why it seems impossible to teach dspam to 
unlearn whitelisting. While doing so, I've stumbled across a bug that appears 
to be unrelated.

In libdspam.c, ca. line 1280:

      if (CTX->classification == DSR_ISINNOCENT)
      {
        if (CTX->flags & DSF_UNLEARN)
        {
          if (CTX->classification == DSR_ISSPAM)
          {
            if (occurrence)
            {
              ds_term->s.innocent_hits -= ds_term->frequency;
              if (ds_term->s.innocent_hits < 0)
                ds_term->s.innocent_hits = 0;
            } else {
              ds_term->s.innocent_hits -= (ds_term->s.innocent_hits>0) ? 1:0;
            }
          }

So if the email is classified as innocent, and the unlearn flag is set, then 
check whether the email is spam before doing anything. How can that be right? 
At this point, the email is already known to be innocent, so the check for 
whether it's spam must always fail.

A similar issue can be found a few lines further down, ca. 1325.

----------------------------------------------------------------------

>Comment By: Jens Finkhaeuser (unwesen)
Date: 2010-12-23 11:03

Message:
Hmm, so, a clarification: I'm not sure if what I found there actually has
to do with unlearning whitelisting, I just found it in my search.

As far as I understand - and I've only just looked into the code - the
DSF_UNLEARN flag is for removing signatures rather than reclassifying them.
If that's true, then removing the second check for classification ==
DSR_ISSPAM should be all that's required to fix it. And the same for the
spam case further down, around 1325.

If that's not true, well, then I don't understand the code enough yet :)

As I understand it, it's the case where DSF_UNLEARN is *not* set that
reclassifies messages, and that might therefore influence whitelisting. But
that's really another problem, so I'll open another issue for that.

----------------------------------------------------------------------

Comment By: Stevan Bajic (sbajic)
Date: 2010-12-23 07:12

Message:
Hallo Jens, can you check if the included patch would fix the issue?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3141675&group_id=250683

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel

Reply via email to