https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6565

--- Comment #1 from Mark Martinec <[email protected]> 2011-04-01 18:57:07 
EDT ---
(> Everything of the from 
> eval:check_rbl_sub('<whatever>', '127.0.0.1') 
> should be replaced with 
> eval:check_rbl_sub('<whatever>', '^127\.0\.0\.1$')
> 
> "." means "any one character" in the perl regexes used to define these, and
> these will match any substring in an IP if it doesn't start with "^" and end
> with "$".  So...
> 
> 72_active.cf:header     RCVD_IN_DNSWL_HI       
> eval:check_rbl_sub('dnswl-firsttrusted', '127.0.\d+.3')
> 
> will match 127.0.0.3, but it will also match 127.0.103.2.
> Which doesn't happen because DNSWL doesn't currently have
> any three digit numbers in the third octet.
> 
> I'm not seeing any cases where it looks like this is likely to currently
> be causing problems.

Thanks for opening the ticket. Except for the first example, the rest is
correct, dns eval rules like '127.0.\d+.3' need fixing. Seems to be much
fewer of them than what I remembered.

What is not true is that an eval:check_rbl_sub(..., '127.0.0.1') needs
fixing. It doesn't, see Mail::SpamAssassin::Dns::process_dnsbl_set :
not all arguments to check_rbl_sub are regular expressions. The subroutine
tests first for exact equality, then checks for a single integer
(which implies a bitmask), and only if all this fails, the argument
is considered a regular expression. So, a '127.0.0.1' is alright, but
the '127.0.\d+.3' is not, it should have been a '^127\.0\.\d+\.3\z' (in
case of a leading 3-digit '127' the '^' anchor may arguably be omitted).

Similarly the eval tests in URIDNSBL.pm and in AskDNS.pm plugins are
quite sophisticated about their eval arguments, accepting several possible
syntaxes before falling back to interpreting it as a regular expression.

-- 
Configure bugmail: 
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to