You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2005/01/01 18:33:55 UTC
[Bug 4058] New: Feature Request: whitelist_subject and blacklist_subject
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
Summary: Feature Request: whitelist_subject and blacklist_subject
Product: Spamassassin
Version: 3.0.0
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: spamassassin
AssignedTo: dev@spamassassin.apache.org
ReportedBy: wnjok@blacklightning.com
CC: wnjok@blacklightning.com
whitelist_subject and blacklist_subject would be very handy.
I would envision them working like the whitelist_from and such but operating on the subject line.
In fact, it would be handy to have this operate on all header lines and the body. It would be a simple
and easy way to make custom rules which is difficult or impossible for many users who don't have
sufficient access privilages. Using whitelist_subject one could have a subject line password that would
let in mail. For example:
whitelist_subject *ABCDEF*
would give any incoming mail containing ABCDEF in the subject -100 points making it very likely to get
through the SpamAssassin not marked as spam. This way one could give out ABCDEF as a password to
put in the header. This is unlikely to get abused by spammers. I've been doing this for a decade. Adding
whitelist_subject to SpamAssassin would make this easier.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
parkerm@pobox.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From parkerm@pobox.com 2005-01-15 00:19 -------
This is the perfect thing for a plugin to handle and since it seemed like an
interesting problem, I wrote one:
http://wiki.apache.org/spamassassin/WhiteListSubjectPlugin
I suppose we could discuss folding it into the SA source proper, but I don't
know how useful it would be for the masses.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
wnjok@blacklightning.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
------- Additional Comments From wnjok@blacklightning.com 2005-01-15 16:44 -------
A plugin is great for those who can install them.
Unfortunately I can't due to limits at my sever.
I do think this would be useful for the masses
if they understood they could use it to provide
an email password that a sender could use to
get through the spam filter without having to
add every sender to the whitelist.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] [review] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From lwilton@earthlink.net 2005-01-15 22:31 -------
Subject: Re: [review] Feature Request: whitelist_subject and blacklist_subject
> I don't really want to have 17 bajillion plugins in the standard dist.
>
> If it's really useful, put it in the main code. If it's useful, but
> possibly/likely to be disabled by a decent number of people, make it a
> standard plugin. If it's useful for some, but not most/all, just put
> it up on the wiki as a plugin people can install themselved.
Let me suggest a differrent viewpoint, based on the concept of sites where
there is a central administration (who are the only ones that can install
plugins and enable them, currently) and users that might be able to write
their own overrides and possibly rules (if allow_user_rules is set). While
this isn't a popular configuration with the developers, there seem to be a
fair number of sites that do work this way.
Even with allow_user_rules, a user can't use plugin functionality if the
plugin isn't there. In fact, they can't even use the plugin if it is there
and wasn't enabled site-wide, currently. As more stuff moves to plugins (as
it likely will), this degrades the concept of allow_user_rules, and possibly
even individual user config options, if the plugins haven't been installed
or enabled by the central site administration.
It appears that currently plugins, along with their register_xxx functions,
can do almost anything internal code can do, and possibly do it just about
as efficiently. It therefore strikes me as likely that a lot if internal
code will probably start getting factored out into plugins just to simplify
the code and make it more readable. Thus, per-user rules and options are
likely to become less capable with time as more stuff migrates to plugins,
especially if all of the plugins are optional and/or not enabled by default.
Based on that, I would be inclined to include the widest possible number of
plugins in the base release, so that the widest possible number of rules are
potentially available, even on a decentralized site with centralized
infopriests in charge of enabling options.
I would also look at the idea of either having all found plugins enabled by
default, or possibly enabled unless a central disable option was present, or
optionally enable-able by jive users in individual user configs. (There
might be a central option to allow users to enable plugins. In fact,
allow_user_rules is already a central option that would fit that purpose.)
So I would be strongly in favor of including the maximum number of
known-working plugins with the base and patch releases. If the plugin isn't
enabled, nothing is lost but a tiny amount of disk space.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] [review] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From felicity@kluge.net 2005-01-15 20:40 -------
Subject: Re: [review] Feature Request: whitelist_subject and blacklist_subject
On Sat, Jan 15, 2005 at 08:23:36PM -0800, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> [X] Include this plugin as is in standard dist (possibly backport to 3.0)
I don't really want to have 17 bajillion plugins in the standard dist.
My POV is something along the lines of:
If it's really useful, put it in the main code. If it's useful, but
possibly/likely to be disabled by a decent number of people, make it a
standard plugin. If it's useful for some, but not most/all, just put
it up on the wiki as a plugin people can install themselved.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] [review] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From wnjok@blacklightning.com 2005-01-15 20:23 -------
[X] Include this plugin as is in standard dist (possibly backport to 3.0)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] [review] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
parkerm@pobox.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Feature Request: |[review] Feature Request:
|whitelist_subject and |whitelist_subject and
|blacklist_subject |blacklist_subject
------- Additional Comments From parkerm@pobox.com 2005-01-15 19:33 -------
I suppose I could put it up for review.
Here are the options:
[ ] Do not include this plugin in the standard dist
[ ] Include this plugin as is in standard dist (possibly backport to 3.0)
[ ] Include this plugin, but also move all of the whitelist/blacklist_* stuff
into the plugin.
Any other thoughts?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] [review] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From quinlan@pathname.com 2005-01-15 19:37 -------
Subject: Re: [review] Feature Request: whitelist_subject and blacklist_subject
Not needed on HEAD since it's C-T-R, but since you ask...
> [X] Include this plugin, but also move all of the whitelist/blacklist_* stuff
> into the plugin.
++1
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From parkerm@pobox.com 2005-01-15 14:18 -------
Subject: Re: Feature Request: whitelist_subject and blacklist_subject
Opps, I'll see if I can find some time to fix it so it works with
3.0.2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] [review] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From quinlan@pathname.com 2005-01-15 21:04 -------
Subject: Re: [review] Feature Request: whitelist_subject and blacklist_subject
> If it's really useful, put it in the main code. If it's useful, but
> possibly/likely to be disabled by a decent number of people, make it a
> standard plugin. If it's useful for some, but not most/all, just put
> it up on the wiki as a plugin people can install themselved.
Michael mentioned on IRC that the code is very similar to the current
whitelisting code, so it seems like there's a good opportunity to
generalize the code and get it all together.
Also, given that whitelisting rules already have options that form the
core of the rule (like other plugins, but not like your standard header,
body, etc. rules), I think a plugin makes great sense for *this* code.
Daniel
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4058] Feature Request: whitelist_subject and blacklist_subject
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4058
------- Additional Comments From spamassassin@dostech.ca 2005-01-15 11:47 -------
Just an FYI: the plugin will only work with the current trunk version since
'register_commands' (in Mail::SpamAssassin::Conf::Parser) isn't in 3.0.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.