Hi! Thanks for the feedback! I'll try to answer the best I can. Please note that the scores are just an example. I'm not really sure what would be appropriate for the general user.
----- "Karsten Bräckelmann" <[email protected]> wrote: > On Sun, 2010-02-28 at 01:40 +0000, João Gouveia wrote: > > http://mailspike.org/anubis/implementation_sa.html > > I guess the rule definitions are slightly broken. After all, the ZBI > meta especially is meant to counter multiple hits. However, since the > plain Z eval() rule does not have a score assigned, it still *does* > get > a default score of 1.0. Nice catch. It should be __RCVD_IN_MSPIKE_Z instead. I'll fix that right away. > I'm also slightly irritated by the meta logic. A Z listed "spam wave > participant" only hits ZBI and thus its 4.1, if they are NOT also > listed > with a poor reputation. That applies to senders with no previous > reputation data, as well as ones with a *good* reputation otherwise. Good[1] reputation senders should never be in Z. The code that dumps the zones into rbldnsd format prevents this (our should prevent this, naturally I can't give any guarantee that this is bug free). As for the bad/neutral senders, I see your point. What logic would you suggest instead? The basic premises are: 1) A good sender should never be in Z 2) A bad sender can also be in Z 3) The meaning of Z is different from Bad reputation (the first one is based on seen spam waves, the second is behavior over time) > On the other hand, a L3 "low reputation" listing prevents ZBI hits, > and > scores the 2.9 of L3 only. This is because there's a big overlap between Z and L3-5. The 4.1 in Z was supposed to act like like a confirmation in this case. Latest data I have from a sample live stream: 167972 IPs of zbi (171919) also hit rep (97.704151373612%) Again, what would be your suggestion? > Compare that to the above with a good > sender, > both currently listed in Z. Is that actually intended? > > Ah, well, the default 1.0 for Z in this case makes up for that -- > turns > the 2.9 into a 3.9 almost equal to 4.1... A good[1] sender should never be listed as a bad sender or Z at the same time. I'm not sure what you mean here, but the 3.9 being almost equal to 4.1 was not on purpose. > > What listing and scoring logic did you actually mean? Feel free to > give > a verbal rather than logic expression. :) If you didn't understand the logic, than I'd say that it's probably wrong :-) The goal was simply not to penalize too much bad senders that are listed both in L3-5 and Z. > Also, what I wondered about, can a single IP really have multiple, > different listing results? I should go dig into the code on this. Yes it can. > > On a side note, the very brief "Bad" comment on your actual base > check_rbl() eval rule is quite irritating on a first look. Kind of > gives > the impression of a bad example, with better rules following... That's because there was a "Good"[1] comment after that one for the H3-5. I left that out because it may induce users into thinking that it's some kind of whitelist, which is not. And, truth be told, it's not useful as a isolated rule. It was something like: ## Good header __RCVD_IN_MSPIKE_F eval:check_rbl('mspike-firsttrusted', 'wl.mailspike.net.') tflags __RCVD_IN_MSPIKE_F net header RCVD_IN_MSPIKE_H3 eval:check_rbl_sub('mspike-firsttrusted', '^127.0.0.18$') describe RCVD_IN_MSPIKE_H3 Good reputation sender (3) [1] As explained in the web site: "The listed IP addresses may occasional send spam but since they originate mostly legit traffic, they should not be blocked. This list can be used as a feature when determining if a message should be considered spam or not, but it should never be used for whitelisting purposes." > guenther > > > -- > char > *t="\10pse\0r\0dtu...@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; > 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; }}}
