> > The main problem with this approach is that it requires monitoring > > of the SPAM assassin tests being applied as the software is > > updated... > > Well, I'd say this is a problem chiefly because whoever _is_ > administering the server -- not spamassassin.apache.org -- is clearly > not encouraging the use of granular client-side filtering.
While true, it is not necessarily the cause of the "problem". I've been using small text strings for my filters to cover a number of SpamAssassin tests, mainly for the convenience of not having to include a separate filter for each individual test. The problem I've had is that while tests that have the same text strings are often similar in nature/function, there are often additional similar tests that have slight variations of these text strings. Including these would require complicating the filter(s) and also require revising the filter with each upgrade. Finding the intial text string to use is also a very unscientific process of collecting test results and examining them manually... rather more of a hack than a procedure (albeit a very effective one). > If filtering on more than the Spam Score were an expectation from > end-to-end, you would have a consistently updated list provided to you > by your mail admin, through an intranet portal or whatever. It's a > virtual certainty that your mail admin is using rules and metas that > don't ship with SA. What would you do about those? In theory, also true, but that's a whole different can of worms. My aim has been to stay out of the can of worms and simply make better use of what we have. In our case, responsibility for determining what is and isn't spam rests entirely with the user (apart from a conservative server-side rejection of score >15). I'm not going to argue whether that's right or wrong... but it's the situation that we're in, and there is some scope for making things more efficient for the end user. A consistent naming convention would make it easier/more efficient for end users to filter out certain groups of messages regardless of what the server admins were or weren't doing. Server admins could also use these conventions for any custom filters they created to provide additional "improvements". Cheers Ben Kreunen Imaging and IT Coordinator Department of Pathology The University of Melbourne
