check_rbl_txt and multiple elements

[Marc Andre Selig <a2...@sedacon.com>]

Dear list members,

upgrading to Debian Jessie has brought SpamAssassin 3.4.0 to a private
server of mine.  For its particular use case, I like to directly assign
scores to autonomous systems whose owners provide snowshoe spamming
services.  (I realize this strategy may be less useful for large mail
hosts, but for this system, it works perfectly.)

Unfortunately, this breaks in 3.4.0.

I use rules such as these:

header   __LOCAL_ASN eval:check_rbl_txt('asn-lastexternal', 'asn.routeviews.org')
describe __LOCAL_ASN Successful ASN lookup from routeviews.org
tflags   __LOCAL_ASN net

header   LOCAL_SPAMMER_BADISP eval:check_rbl_sub('asn-lastexternal', '"4321"')
describe LOCAL_SPAMMER_BADISP AS4321 (Bad ISP, Inc.)
score    LOCAL_SPAMMER_BADISP 3

[... and some more check_rbl_sub tests ...]

The problem is that asn.routeviews.org returns ASN data as TXT records
in this format:

	"4321" "82.200.196.0" "24"

Up to 3.3.2, SpamAssassin made this available to check_rbl_sub as-is, so
the rule given above worked.  3.4.0 however has the following in Dns.pm
(and it's still identical in the nightlies distributed for mass-check):

> sub process_dnsbl_set {
>   [...]
>   my $rdatastr = $answer->UNIVERSAL::can('txtdata') ? join('',$answer->txtdata)
>                                                     : $answer->rdatastr;

As a result, the record given above becomes

	432182.200.196.024

which is impossible to parse (it could be AS 43218 with IP range
2.200.196.0/24, or AS 4321 with IP range 82.200.196.0/24, or even AS
432 with IP range 182.200.196.0/24).

Patching that line to join with a space (join(' ', $answer->txtdata)...)
makes my immediate problem go away, provided that I now look for
'^54321 ' instead of '"54321"' in check_rbl_sub().

Questions:

Why does process_dnsbl_set() join the elements of TXT records directly,
instead of separating them with something?  Is there any chance of having
the old behaviour restored in official releases, or at least having some
separation character in there?

Is there a better way to do what I want?  (I know about Plugin::ASN,
of course, but IIUC it can only be used for tagging, not for assigning
direct scores?)

Full patch appended (there are two more similar cases, one of which is
merely cosmetic).

Regards

Marc

Re: check_rbl_txt and multiple elements

[Marc Andre Selig <a2...@sedacon.com>]

On Fri, May 08, 2015 at 01:55:47PM +0100, RW wrote:

[Plugin::ASN]

> The plugin generates psuedo-headers you can run tests against. X-ASN
> and X-ASN-Route contain   _ASN_ and  _ASNCIDR_ respectively.

Thank you very much!  This is indeed easy to test.

It would be great if this piece of information would find its way into
the Pod text of ASN.pm (at least if it's meant as a stable interface).

Re: check_rbl_txt and multiple elements

[RW <rw...@googlemail.com>]

On Fri, 8 May 2015 13:29:36 +0200
Marc Andre Selig wrote:


> Is there a better way to do what I want?  (I know about Plugin::ASN,
> of course, but IIUC it can only be used for tagging, not for assigning
> direct scores?)

The plugin generates psuedo-headers you can run tests against. X-ASN
and X-ASN-Route contain   _ASN_ and  _ASNCIDR_ respectively.

Re: check_rbl_txt and multiple elements

["Kevin A. McGrail" <KM...@PCCC.com>]

On 5/8/2015 7:29 AM, Marc Andre Selig wrote:
> Questions:
>
> Why does process_dnsbl_set() join the elements of TXT records directly,
> instead of separating them with something?  Is there any chance of having
> the old behaviour restored in official releases, or at least having some
> separation character in there?
 From off-list discussions, here's the answer from Mark:


It would break SPF, DKIM, ADSP and DMARC.

Plugin/AskDNS.pm:

   # RFC 5518: If the RDATA in a TXT record contains multiple
   # character-strings (as defined in Section 3.3 of [RFC1035]),
   # the code handling such reply from DNS MUST assemble all of these
   # marshaled text blocks into a single one before any syntactical
   # verification takes place.
   # The same goes for RFC 4408 (SPF), RFC 4871 (DKIM), RFC 5617 (ADSP),
   # draft-kucherawy-dmarc-base (DMARC), ...

Regards,
KAM