https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6518
--- Comment #4 from Mark Martinec <[email protected]> 2010-12-14 21:44:18 UTC --- trunk: Bug 6518: Plugin::AskDNS now also accepts DNS rcode as a filtering subrule, making it possible to distinguish a NXDOMAIN from other failures; provide tags FIRSTTRUSTEDREVIP and LASTEXTERNALREVIP (first approx) Sending lib/Mail/SpamAssassin/Message/Metadata.pm Sending lib/Mail/SpamAssassin/Plugin/AskDNS.pm Committed revision 1049394. Added/updated documentation section on the filtering parameter (subrule): [...] The last optional parameter of a rule is filtering expression, a.k.a. a subrule. Its function is much like the subrule in URIDNSBL plugin rules, or in the check_rbl eval rules. The main difference is that with askdns rules there is no need to manually group rules according to their queried zone, as the grouping is automatic and duplicate queries are implicitly eliminated. The subrule filtering parameter can be: a plain string, a regular expression, a single numerical value or a pair of numerical values, or a list of rcodes (DNS status codes of a response). Absence of the filtering parameter implies no filtering, i.e. any positive DNS response (rcode=NOERROR) of the requested RR type will result in a rule hit, regardless of the RR value returned with the response. When a plain string is used as a filter, it must be enclosed in single or double quotes. For the rule to hit, the response must match the filtering string exactly, and a RR type of a response must match the query type. Typical use is an exact text string for TXT queries, or an exact quad-dotted IPv4 address. In case of a TXT or SPF resource record which can return multiple character-strings (as defined in Section 3.3 of [RFC1035]), these strings are concatenated with no delimiters before comparing the result to the filtering string. This follows requirements of several documents, such as RFC 5518, RFC 4408, RFC 4871, RFC 5617. Examples: "127.0.0.1", "transaction", 'list' . A regular expression follows a familiar perl syntax like /.../ or m{...} optionally followed by regexp flags (such as 'i' for case-insensitivity). If a DNS response matches the requested RR type and the regular expression, the rule hits. Examples: /^127\.0\.0\.\d+$/, m{\bdial up\b}i . [...] (text on numerical forms) Lastly, the filtering parameter can be a comma-separated list of DNS status codes (rcode), enclosed in square brackets. Rcodes can be represented either by their numeric decimal values (0=NOERROR, 3=NXDOMAIN, ...), or their names. See http://www.iana.org/assignments/dns-parameters for the list of names. When testing for a rcode where rcode is nonzero, a RR type parameter is ignored as a filter, as there is typically no answer section in a DNS reply when rcode indicates an error. Example: [NXDOMAIN], or [FormErr,ServFail,4,5] . -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
