Harald Binkle wrote, On 7/5/08 7:46 PM:
Sorry, I thought a discussion for switching the default behavior would be right
to be
in dev list.
Yes, I'm the one who brought up the related issues of how to handle learning and
whitelisting, and I said what I did to make sure that any further digression to
those
topics should go to the users list. Your questions about changing the default
behavior and
about new eval rules would go in this list.
And what about a discussion about a new eval function comparing the matches of
two
regular expression. If there would be functions eval:Equals(/regex1/,/regex2/)
and
eval:NOTEquals(/regex1/,/regex2/) it would be easy to define rules like the
one I
mentioned in my last mail.
I don't have an immediate opinion about this. Perhaps you could try it out in a
plugin and
see how it works out compared to simply using whitelist_from_rcvd to make the
whitelisting
work.
I did once try to catch that kind of spam with an eval rule that calls
check_forged_in_whitelist which is supposed to catch anything that matched the
address
portion of a whitelist_in_rcvd but doesn't match the received part of the test.
I don't
remember now why we don't have any rules that use that eval, it may be that it doesn't
really work. You might try defining a rule
header FORGED_USER_IN_WHITELIST eval:check_forged_in_whitelist()
and also define some whitelist_from_rcvd entries and see if that rule has any
success at
catching those.
-- sidney
