Re: [Sqlgrey-users] idea for improving Discrimination feature

[Dan F. <da...@ha...>]

Riaan Kok wrote:
>> When more than one rules match (which is likely), which one gets 
>> displayed
>> in the logs?  Does the last one that matches gets displayed, or does  
First match wins and "searching" stops.
> a case that I saw in the logs intrigued me, so I did a quick lookup of 
> the
> keys() function and read a bit about hashes..  Perl's hash structure 
> is not
> ordered in any way.  So, iterating through a hash returns the elements in
> undefined order..  
Yeah.. Basically the rules gets ordered by postfix_attrib. 
Postfix_attrib's gets randomly ordered.
So eg. all helo_name's might get run first, then all client_name and so 
forth.

> There's not much point in
> gathering statistics then!
I added the rule_nr to help our support department. Apparently, many of 
our customers have mailserver-software that acts REALLY weird on 45X 
errors. Some bounce, some send a mail that looks like a bounce telling 
the sender that it got a 45X but will keep trying and more odd stuff 
like that.
So to enable our support department to help the customers bypass our 
rules, they needed to know what rule nailed the client.

And i personally like to sometimes grep for which rules nails most. I 
dont see what you gain by knowing which other rules didnt catch the spammer.

> (By the way, this could be related to what you
> referred to in the code regarding resetting the hash.)
What im referring to, is that "while ... each" doesnt start from the top 
of the hash the second time the function is called.. "each" only returns 
last element. Using "keys" at top of the function fixes this oddity.

> So, how about rather storing the list of rules in an array, which does 
> away
> with the need for storing the $rulenr, and each array item like $rule
> containing:
> $rule->{attrib}
> $rule->{oper}
> $rule->{regexp}
Hmm well.. Its seems like a lot of work for a very small result. I dont 
think ill be coding this anytime soon ;).. But if youre a perl coder, 
patches are welcome.

>   Sqlgrey normally indicates at log level 2 whether a
> given smtp combination passes awl, gets greylisted, is new, etc., so
> indicating that greylisting is bypassed due to no regexp match makes 
> sense
> to me to be at level 2 as well..
My initial reason for putting it on level 3 is the size of our 
mail-logs. But i guess i dont mind moving it down to level 2, as it 
probably does makes more sense.
>
> And, yet another suggestion: it could be useful to include in one or 
> more of
> the documentation locations a quick list of postfix attributes that 
> can be
> used with discrimination..
I was actually about to do that when i made the 1.7.4 release, but then 
it got all confusing with different versions of Postfix giving different 
attributes. So i decided not to, and instead made some examples showing 
the most useful postfix attribs.
If you have compiled a list of attribs that work with your postfix 
version, i can include that in the docs in 1.7.5.

- Dan