On Wed, 2008-05-14 at 15:03 -0400, Aaron Bennett wrote:
> Karsten Bräckelmann wrote:
> >
> > Please check the recent archives for threads
> > about the VBounce plugin or backscatter.
>
> I apologize for not doing that... however, had I, I would have still
> asked the question because the advice given is not suitable for an
> enterprise deployment:
>
> > # If you use this, set up procmail or your mail app to spot the
> > # "ANY_BOUNCE_MESSAGE" rule hits in the X-Spam-Status line, and move
> > # messages that match that to a 'vbounce' folder.
>
> If you read further you'll see that you didn't answer my original
> question....
That's because (a) I am not using the rules the way you asked about,
but as intended and documented, and (b) your original question is wrong
in itself:
"do you see them working with the default scores,
or have you tweaked them"
Yes, these rules are working. A score of 0.1 is intended, and the entire
purpose of having *any* non-zero score is, to not disable the rules.
Hitting ANY_BOUNCE_MESSAGE for blowback mail means, that it is working
and *identifying* bounces. VBounce is NOT intended to push bounces above
the spam score threshold, because it is not considered spam.
But read on below.
> >> My question is to people who've been using the rules in a real
> >> production environment -- do you see them working with the default
> >> scores, or have you tweaked them at all?
>
> Using procmail or a client side filter to file spam based on an
Who said "client side"?
> X-Spam-Status line is not appropriate for a large, or even moderately
> large, end-user focused deployment -- that's why I asked if others are
> altering the default scores.
You can use whatever tool you want from your mail processing arsenal, to
act "accordingly" on mail that hits ANY_BOUNCE_MESSAGE. The recommended
way is, to put 'em aside for (possible) later review. You don't have to
use procmail. And certainly, "client side" isn't even anywhere in the
picture as per the docs.
Repeating that backscatter is not spam, and agreeing with the author of
VBounce on this...
You can handle backscatter as you want. If it is your policy to treat
them the same as spam, just do that. It's remarkably easy to change a
rules score in SA -- and actually a fundamental design decision.
> Again, a thousand apologies for making you repeat yourself.
>
> That all being said...
>
> Is anyone using these rules for spam detection? If so, how have you
It is not spam. :)
> been scoring them? I'm glad to have a confirmation that 0.1 is
> obviously not enough but I'm curious how others are scoring these rules;
> given a general spam target of 5. I'm thinking of scoring in the range
> of 1.5 - 2...
Those who mentioned similar policies before usually do use a much higher
value. For a number of reasons:
(a) They usually want backscatter to score above a kill threshold,
resulting in the mail being BLOCKED and NOT accepted.
(b) A score of 2 wouldn't even push a lot of backscatter above the spam
threshold.
(c) Backscatter, identified by VBounce, does NOT necessarily include the
original body. Thus, spam tests will fail, because there is no
fodder for Bayes, or URIBLs. Other blacklists based on Received
headers won't hit either.
(d) A lot of other stuff mentioned before, I just forgot...
Especially (c) is about the Out of Office replies, Retired Addresses and
Challenge Response crap. Without Bayes, those are likely going to score
a mere 2, given your proposed score. With Bayes, they may even end up
with a negative score.
That all said, here's it again in a nutshell: Intended usage for
VBounce is to *identify* bounces by hitting the ANY_BOUNCE_MESSAGE rule,
and treat them accordingly. Suggested action is, to move them aside.
Optional, you are free to treat them as spam, if that is your policy.
However, in that case, you better make sure it passes your spam score
threshold.
guenther
--
char *t="[EMAIL PROTECTED]";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
