Sidney, thank you very much for your answers and explanations. I just looked over the code of check_forged_in_whitelist and think it's hard to use for my intention. I will wait some days if someone else will replay to the request of implementing eval:Equals(/regex1/,/regex2/) and eval:NOTEquals(/regex1/,/regex2/). If no one will answer I'll post that request with a correct (more appropriate) subject in one or two weeks to the dev list again and see what others say. The problem I have is, that we use the windows version of SpamAssassin (http://sourceforge.net/projects/sawin32/) so just implementing a plugin providing those two functions is not easy (much work).
I think those evals would give the option to write more powerful rules without the need to implement little things in plugins as it is not possible to compare matches of regular expression within the same regular expression. Harry > -----Original Message----- > From: Sidney Markowitz [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 10:19 AM > To: Harald Binkle > Cc: '[email protected]' > Subject: Re: shortcircuit for USER_IN_WHITELIST --> noautolearn?? > ==>learn! > > 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 ---------------------------------------------------- JAM Software GmbH Gesch?ftsf?hrer: Joachim Marder Bruchhausenstr. 1 * 54290 Trier * Germany Tel: 0700-70707050 * Fax: 0700-70707059 (max. 12,4 ct/min, Preise aus Mobilfunknetzen k?nnen abweichen) Handelsregister Nr. HRB 4920 (AG Wittlich) http://www.jam-software.de
