Bug 4440 - unblacklist_from non-functional in certain cases
Summary: unblacklist_from non-functional in certain cases
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.0.3
Hardware: PC Linux
: P5 normal
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-29 20:54 UTC by brian
Modified: 2009-03-29 14:59 UTC (History)
0 users



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description brian 2005-06-29 20:54:00 UTC
Using the following in user_prefs:

blacklist_from *@*
unblacklist_from foo@bar.com

Results in USER_IN_BLACKLIST for all incoming e-mail from foo@bar.com,
indicating that foo@bar.com isn't being unblacklisted.
Comment 1 Michael Parker 2005-06-30 11:25:24 UTC
I just took at brief look at the code, and I honestly can't see how this works
at all, unless you have exact matching addresses.

blacklist_from *@* adds *@* to a data structure

unblacklist_from foo@bar.com just deletes foo@bar.com from that data structure,
but there is no entry for foo@bar.com.

What probably needs to happen is two lists, the normal blacklist/whitelist (yeah
whitelist uses the same code) and some sort of exclusion list, if the first
matches, you need to check the second to see if that specific address is excluded.

Should tackle for 3.1
Comment 2 Duncan Findlay 2005-06-30 12:45:53 UTC
Michael, what you are describing was the intended behaviour as it was designed.

The (original) purpose of unblacklist was so that a sitewide configuration or a
user could override a distributed or sitewide blacklist options. It is not to
implement negative/conditional logic.

The long term solution is probably take all the blacklist/whitelist stuff and
put it in a plugin, and refactor it then. I don't think this can/should be done
before 3.1.

Moving to 3.2.0... We can play bugzilla pong if you disagree! :-)
Comment 3 Duncan Findlay 2005-06-30 12:57:58 UTC
I've fixed the documentation for 3.1 (No vote needed for doc fixes, right?)
Comment 4 Michael Parker 2005-06-30 13:02:32 UTC
While it's true that this is "Documented" behavior, I'm certain that there is a
better way to do it.  In fact, there might already be another bug out there
because I'm pretty sure we've talked about this before.

We can keep the 3.2.0 milestone, but I don't promise that I won't go ahead and
come up with something before then.
Comment 5 Justin Mason 2006-12-12 12:40:17 UTC
moving RFEs and low-priority stuff to 3.3.0 target
Comment 6 Justin Mason 2009-03-29 14:59:30 UTC
moving this low-priority issue off a concrete milestone, into "Future"