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.

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.

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

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.

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?

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

[X] Include this plugin as is in standard dist (possibly backport to 3.0)

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.

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

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.

> [X] Include this plugin, but also move all of the whitelist/blacklist_* stuff
> into the plugin.

+1 for me too.  and enable it by default ;)


Loren -- IMO, if any code is moved from the existing code into a plugin, that by
definition needs to be one of the default-enabled plugins for future releases
(unless there's a very good reason otherwise).

> [X] Include this plugin, but also move all of the whitelist/blacklist_* stuff
> into the plugin.

+1 for me too.  and enable it by default ;)


Loren -- IMO, if any code is moved from the existing code into a plugin, that by
definition needs to be one of the default-enabled plugins for future releases
(unless there's a very good reason otherwise).

Setting 3.1.0 milestone -- I'm *NOT* saying we want to do this for 3.1.0, but
I don't want to forget about it before 3.1.0, thanks Bob for pointing out this
bug.

My inclination is to actually defer to 3.2.0 given the late timing.

Well, with my +1 that is three for pulling all of the whitelist code into a plugin.

Theo, would you veto such a change?

Subject: Re:  [review] Feature Request: whitelist_subject and blacklist_subject

On Mon, Apr 11, 2005 at 12:14:12PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> Well, with my +1 that is three for pulling all of the whitelist code into a plugin.
> Theo, would you veto such a change?

I think I'm -0.5 or so at the moment.  I don't really see a benefit to moving
the code to a plugin, but if others want to do it I'm not going to stop you.

Suggestion to improve things.

Really, this bug occurs mostly because there are two algorithms for inferring
trust when private/reserved IPs exist.

1) Trust all reserved IPs, plus first non-reserved. 

2) Trust all reserved IPs, first non-reserved untrusted.


Algorithm 1) works if your outer-most MX has a non-reserved IP, and fails with
over-trust if your outer-most MX is using some kind of static-mapped NAT or
other mechanism that gives it a reserved IP.

Algorithm 2) works if you have a NATed MX, but fails with under-trust if your MX
is not NATed.

Why not add a config option that will control if SA assumes the MX is NATed or
not?  

i.e. trusted_networks_nated_mx  (default disabled)

This would at least make it easy for people to fix, and obvious in the manpage
they might want to consider it. 

Misdirected comment, Belonged on 4055, not sure how bugzilla put it here.

Added WhiteListSubject plugin in r180222, decided that moving all of the
whitelist stuff was too large a change, it's a possible future improvement, but
not for now.