http://bugzilla.spamassassin.org/show_bug.cgi?id=3421
------- Additional Comments From [EMAIL PROTECTED] 2004-05-24 22:39 -------
Subject: Re: clean-up DNSBL API
> We need a better API. This is, after all, a public API; when we
> change the ordering or the selection-of-IPs mechanism, we're going to
> need to keep backwards compat to avoid third-party breakage.
Agreed, although I think it's okay to break the API in 3.0.
> We have some semantics in the name of the function, some in the set
> string, some in additional arguments... it seems inconsistent, messy,
> and hard to support ongoing.
Agreed.
> thinking: should this be an eval test at all? should we just define a
> new rule type? Why is a DNSBL lookup a "header eval test" in the
> first place, apart from historical accident?
Makes sense. (To be clear, not as a plug-in, though.)
> What about this...
>
> dnsbl NAME_OF_TEST setname zone [name="value" ...]
>
> where the "name=value" pairs can contain:
>
> type="{A,TXT}" type of query
> sub="{1,0}" 1 for check_rbl_sub semantics
> subpattern="127.0.0.[456]" pattern for sub tests
> subbit="4" bitwise AND pattern "
> subsbeval="(S2 / S9) > 5.00)" Senderbase eval "
> ipset="{all,firsttrusted,untrusted}" select IPs to test
>
> and any future ones we care to add....
1. DNS query type - makes sense
2. instead of "ipset", I'd define a general type of "input" which
dictates the things we're testing. First, I'd include the non-IP
types of queries into this, so that distinction needs to be made:
- IPs vs. names/hosts (sometimes RHS, but RHS is not really the correct
term since HELO and reverses can be tested too)
- for both IPs and names, there is the question of which exact ones
maybe specify as a joined pair:
input="{class:subclass}" like "ip:notfirsthop" or whatever
3. Instead of sub and the sub*, I'd go with something like:
result="{any,bit,pattern,sb}[:{definition}]" like "bit:4"
(where the definition is left off for the "any" type)
If the subtyping of (2) and (3) doesn't work for you, I suppose, we
could go with something like "class" and "selection" for (2) and
something like "result" and "pass" for (3).
By the way, if you have to specify the zone, then there's really no
point in keeping around sets, just use the rule name of the master rule.
It might make sense to keep around the distinction between sub-tests and
starter-type tests. I'm even thinking about whether or not we should
just make all starter-type specifiers to not be rules (a few are already
__RULE so they get no score). Then, all rules would be subrules, some
of the type "any".
Then you'd have:
1. dnsquery setname zone [name="value" ...]
The starter.
2. dnstest NAME_OF_TEST setname [name="value" ...]
The result(s).
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
