Hello Jeff, Wednesday, March 9, 2005, 1:00:33 AM, you wrote:
>> 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. JC> This is something that could potentially be useful to SURBLs as a JC> whitelist source (used for exclusion from SURBLs), so I'm in JC> favor of it. Daryl's ideas of a web form feeding a database JC> and a separately named rule to use it within SA seem like good JC> suggestions. In that a whitelisted "from" domain can be assumed to reference its own domain in URIs within its emails, I agree. A SURBL whitelist probably should contain these primary domain names, to ensure that spammers don't pollute SURBL by using/abusing these domains. Theo's comment about being able to skip SURBL checks is a good idea also. JC> Because this would be a centrally maintained, hand-edited list I JC> don't see it occupying the exact same space as SPF. Agreed. It will acknowledge/use SPF as much as possible, but it will extend past SPF by making determinations of "not a spammer", which SPF itself cannot do. JC> Ultimately something like an RBL may be the best way to get JC> the data out unless the list is relatively static and not JC> too large. Yes ... the list will be relatively static, probably have a fast growth period at some point, but unlike spammers it won't be continually morphing. I don't see it getting large enough to warrant an RBL for a long while, but eventually it might be useful. JC> As you outline it above it seems like it would be a global JC> publishing of local whitelists where there was strong consensus JC> about what should be whitelisted. That could be a subset of JC> the local whitelist_froms of all SpamAssassin installations. JC> It could also grow into something larger, and that's not JC> necessarily a bad thing. Collecting up SA local whitelist_froms JC> is a reasonable place to start. Problem with the whitelist_from's is that they don't have the rcvd information needed to prevent abuse. Change that to a collection of local whitelist_from_rcvd's, and I would agree with you completely. Bob Menschel
