[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-devel
Subject:    [Bug 7791] New: Intermittent results from DNS/ASN when used via spamd
From:       bugzilla-daemon () spamassassin ! apache ! org
Date:       2020-01-29 6:37:29
Message-ID: bug-7791-26 () https ! bz ! apache ! org/SpamAssassin/
[Download RAW message or body]

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7791

            Bug ID: 7791
           Summary: Intermittent results from DNS/ASN when used via spamd
           Product: Spamassassin
           Version: 3.4.3
          Hardware: PC
                OS: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: spamc/spamd
          Assignee: dev@spamassassin.apache.org
          Reporter: mark-apache@xwax.org
  Target Milestone: Undefined

I'm attempting to match against a particularly agressive spammer's ASN, but
results are only intermittent.

Test case is almost verbatim based on the Mail::SpamAssassin::Plugin::ASN(3)
man page, using a mail sent from gmail.com web interface.

    rbl_timeout 60 20
    asn_lookup_ipv6 origin6.asn.cymru.com _ASN_ _ASNCIDR_

    header ASN_GOOGLE    X-ASN =~ /^15169$/
    describe ASN_GOOGLE  Originates from Google's ASN
    score ASN_GOOGLE     -0.1

The rule only matches intermittently, yet the X-Spam-ASN (and _ASN_ value) is
always available.

I seem to get reliable answer when testing 'spamassassin < msg' on the command
line.

For the same via spamc, results are intermittent for the same message tested
over and over again, but often they are succesful.

When I actually receive mail into sa-spamd via Exim in practical use, it's very
rare for the rule to match.

In all cases, the message is processed quickly (well below 1s) and I extended
rbl_timeout to ensure all DNS results are processed.

In all cases, _ASN_ information in the report is available (and X-Spam-ASN
header can be seen using spamc/spamassasin command).

It doesn't seem to be connected to mail originating from IPv6 vs. IPv4.

With spamc, there is a tendency (but not always) for subsequent requests to be
successful which makes me thing some kind of timing bug based on DNS caching
may be happening.

I am using a local DNS resolver which seems to consistently show successful
lookup in all cases:

    info: 127.0.0.1
9.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.origin6.asn.cymru.com.
TXT IN
    info: 127.0.0.1
9.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.origin6.asn.cymru.com.
TXT IN NOERROR 0.000000 1 177

Here's an example of the intermittency in the result from spamc:

    X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
            DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,
            RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
            autolearn_force=no version=3.4.3
    X-Spam-ASN: AS15169 2a00:1450::/32

A few seconds later running the exact same message:

    X-Spam-Status: No, score=-2.2 required=5.0 tests=ASN_GOOGLE,BAYES_00,
            DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,
            RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable
            autolearn_force=no version=3.4.3
    X-Spam-ASN: AS15169 2a00:1450::/32

-- 
You are receiving this mail because:
You are the assignee for the bug.=
[prev in list] [next in list] [prev in thread] [next in thread]