On 12/02, Karsten Bräckelmann wrote: > How very subversive... I asked in the bug how people felt about posting to the users list about it. I got no objections.
The complete lack of responses from anybody but you in the last 4 days seems to be a loud and clear indication that nobody cares, and we should go ahead with adding this useful blacklist. > On Thu, 2011-12-01 at 12:58 -0500, dar...@chaosreigns.com wrote: > Since you keep stressing the one, 1, single DNS query per message, I > cannot help but nit-pick -- please do have a look at the rules you're > talking about. Or maybe, just re-read your own comment 1 on bug 6400. > It's not a single query. Yup, sorry. I made the mistake of assuming the mailspike instructions would included everything, but turns out it's just the blacklist: http://mailspike.org/usage.html Only part I care about is the blacklist. > > If it does get added, it will be following a post to this list. If you > > want to ensure you do not use this blacklist if it does get added, you can > > preemptively disable it with: > > You forgot to disable and meta-out the sub-rules, most notably including > the actual check_rbl() eval rules doing the queries. You just disabled > the scores but did not eliminate the DNS queries. > > I have pointed out such omission in the past, a couple times. That does sound familiar. Seems odd that that's necessary. So it should look like this? score __RCVD_IN_MSPIKE_B 0 score __RCVD_IN_MSPIKE_L 0 score __RCVD_IN_MSPIKE_Z 0 score RCVD_IN_MSPIKE_L5 0 score RCVD_IN_MSPIKE_L4 0 score RCVD_IN_MSPIKE_L3 0 score RCVD_IN_MSPIKE_L2 0 score RCVD_IN_MSPIKE_H5 0 score RCVD_IN_MSPIKE_H4 0 score RCVD_IN_MSPIKE_H3 0 score RCVD_IN_MSPIKE_H2 0 meta __RCVD_IN_MSPIKE_LOW 0 meta RCVD_IN_MSPIKE_ZBI 0 meta RCVD_IN_MSPIKE_BL 0 meta RCVD_IN_MSPIKE_WL 0 > > We would prefer to only add this blacklist to future releases, version > > 3.4.x+. But we currently do not have a way to maintain two separate sets > > of rule updates. So our options are: > > Discussing exactly this on the dev@ list would have been quite some > idea, don't ya think? I thought that question had already been sufficiently implied. > > 4) Develop a way to maintain two separate rule sets. May, realistically, > > be impossible. > > I wonder how hard running the re-scoring twice could be -- one time with > the relevant rules snipered from the mass-check logs. Well, for the time > we keep updating 3.3.x update channels in addition to the then-current > 3.4.x, which is something not even discussed. That might be great. When do you think that's likely to happen? > > 5) Add new blacklists to 3.4.x rules, and stop providing 3.3.x updates. We > > can't expect people to just cut over suddenly like that. > > True on the latter. However, there have been no plans (or discussion) > yet about generating frequent rule updates for the current stable, *and* > previous release. Stopping the updates does NOT suddenly invalidate the > previous version. People today still happily running 3.2.x can tell you. > > Ironically, you're the one who pushed for 3.2.x EOL. Now your aim seems > to be not only to maintain two stable versions, but also to keep > generating rule updates long-term. I wanted 3.2.x to be supported *or* for the lack of support to be clearly stated. It seemed pretty clear it wasn't going to get any support. Mostly because nobody seemed to know how to handle score generation for 3.2. The spamassassin downloads page still looks like 3.2.5 is supported. "A major release is supported for no less than 6 months after the release of the next major release." - http://wiki.apache.org/spamassassin/ReleaseGoals Yes, I think for at *least* 6 months after a release, rule updates should continue to be provided for the previous release. I think 6 months is too short. -- "We will be dead soon. Is this how we want to live?" http://www.ChaosReigns.com
