OK, based on what little discussion there's been so far, here's a draft proposal for people to think about.
Summary: A group of volunteers will maintain a collected/distributed whitelist, using SpamAssassin's whitelist_from_rcvd capabilities, similar to (but in the opposite direction as) William Stearns' collected/distributed blacklist at http://www.stearns.org/sa-blacklist/sa-blacklist.current.cf Goal: There are public newsletters, services, etc., which a) do not spam, and b) can easily be mistaken as spam by SpamAssassin for a variety of reasons (overly aggressive custom rules, wrongly taught Bayes system, paid advertising listing SURBL URIs, etc). Though anti-spam devotees see these as opportunities for cleaning up our system, for the purposes of email reliability we want these emails to go through unhindered. Assumption: This activity will focus only on public newsletters, services, etc., which normally do not contain any private information. Therefore there will not be any privacy or confidentiality concerns for the great majority of emails from these sources. Distribution: The rules file which results from this activity will be maintained within the SARE system, as file 70_sare_whitelist.cf -- it can be downloaded manually or via RDJ. Rules: Since these rules are gathered by the community at large, rather than use the whitelist_from_rcvd rule which normally scores -100, we will use the def_whitelist_from_rcvd rule, which scores only -15. Any site that wishes can copy any of these rules to a def_whitelist_from rule to gain the full -100 points. [Question to the devs: would you agree this is a valid use for the def_whitelist_from_rcvd rule?] Adoption to SA Core: We expect that some/most of these rules will be adopted into the SpamAssassin core distribution when new releases are issued. At such times, rules adopted into SA will be migrated to a stable file named 70_sare_whitelist_pre_vvvvvv.cf (eg: 70_sare_whitelist_pre_030100 for SA 3.1.0). This file will be announced on the SA-Users list, and can be retrieved once into any/all systems. That file will not change. These rules will be deleted from the primary 70_sare_whitelist.cf file concurrent with the official release of the new SA release. Systems that migrate to a new SA release would then be expected to delete all "pre" files, though there wouldn't be any harm other than a minimal performance hit if they do not. Contributions: Anyone within the SA community can submit a single whitelist rule for inclusion into the active rules file, and/or submit a qualifying email (with full headers), from which the whitelist team will create a rule. Submissions with a full qualifying email are preferred. Submissions should be sent to [EMAIL PROTECTED] [Submissions can be sent to that address immediately -- something will be done with them, whether following this proposal or not.] Process: At least at first, we expect many/most of these submissions to be obvious ham sources (such as NYTimes.com would be). Obvious ham sources will be agreed upon unanimously by the whitelist team, and added to the whitelist. Any non-obvious ham source, any that has a majority agreement within the whitelist team but not unanimous agreement, will be examined in detail by one of the team. The results of that examination will be reviewed by the whitelist team, and any that now receives unanimous agreement will be added to the rules file. Any submission which does not obtain unanimous agreement will not be added to the rules file. Any submission which already matches a def_whitelist_from_rcvd rule within the SA distribution will be identified and ignored (after response back to the submitter). (We are not going to try to develop pre-3.0.0 files.) Team members: Anyone within the SpamAssassin community who has submitted a CLA to Apache, and who is accepted unanimously by the whitelist team, can join the team. [The CLA requirement is to ensure that rules can be adopted into the SA without any licensing concerns.] - - - - - - - Can anyone think of any guidelines to be added or changed? Any volunteers willing to help out? Bob Menschel
