SpamAssassin RBL blacklists not checked by Amavis

Discussion in 'Installation/Configuration' started by customhost, May 24, 2020.

  1. customhost

    customhost New Member

    Hi all,
    I recently ran into a strange problem with the Amavis spam score.
    The headers of a received Spam mail contain the following spam score:
    X-Spam-Status: Yes, score=8.418 tagged_above=1 required=4.5
        tests=[BAYES_50=0.8, DCC_CHECK=1.1, DCC_REPUT_90_94=0.6,
        SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01,
        T_PDS_OTHER_BAD_TLD=0.01, URIBL_BLACK=1.7]
        autolearn=no autolearn_force=no
    When I test the mail manually using spamassassin -D -t , I get the following score:
    Inhaltsanalyse im Detail:   (19.1 Punkte, 5.0 benötigt)
    Pkte Regelname              Beschreibung
    ---- ---------------------- --------------------------------------------------
     2.5 URIBL_DBL_SPAM         Contains a spam URL listed in the Spamhaus DBL
     1.7 RCVD_IN_MSPIKE_L4      RBL: Bad reputation (-4)
                                [ listed in]
     3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                                [ listed in]
     1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Transportiert via Rechner in Liste
                  [Blocked - see <>]
     2.7 RCVD_IN_PSBL           RBL: Received via a relay in PSBL
                                [ listed in]
     1.7 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
    -0.0 SPF_HELO_PASS          SPF: HELO-Name entspricht dem SPF-Datensatz
     0.0 T_PDS_OTHER_BAD_TLD    Untrustworthy TLDs
                                [URI: (xyz)]
    -0.0 SPF_PASS               SPF: Senderechner entspricht SPF-Datensatz
     0.0 HTML_FONT_LOW_CONTRAST BODY: HTML-Schriftfarbe ähnlich der
     0.0 T_KAM_HTML_FONT_INVALID BODY: Test for Invalidly Named or
                                Formatted Colors in HTML
     0.0 HTML_MESSAGE           BODY: Nachricht enthält HTML
     0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
     1.1 DCC_CHECK              Als Massen-E-Mail erkannt von DCC (
     0.4 DCC_REPUT_90_94        DCC reputation between 90 and 94 %
     0.0 RCVD_IN_MSPIKE_BL      Mailspike blacklisted
     0.5 FROM_SUSPICIOUS_NTLD   From abused NTLD
     0.1 DKIM_INVALID           DKIM or DK signature exists, but is not valid
     1.5 FROM_FMBLA_NEWDOM      From domain was registered in last 7 days
     0.0 FSL_BULK_SIG           Bulk signature with no Unsubscribe
    As you can see, only the URIBL blacklist was checked through amavisd, the other ones (RCVD_IN_SBL_CSS, RCVD_IN_BL_SPAMCOP_NET, ...) were not. This results in a different score.

    Debian version: 9.12
    Amavisd-new version: 2.10.1
    SpamAssassin version: 3.4.2
    Postfix version: 3.1.14

    The server was set up using this tutorial and runs the latest ISPConfig 3.1.15p3.

    I already made sure that the following is set in /etc/amavis/conf.d/20-debian-defaults:
    $sa_local_tests_only = 0; 
    And added the following to /etc/spamassassin/
    dns_server # added to fix blocking of URIBL and DNSWL queries

    Does anyone know what the problem could be?
  2. Steini86

    Steini86 Active Member

    Have you done any settings in ISPConfig?
    ISPC -> Mail -> (Spamfilter) User / Domain -> see what policy is set
    Then under "policy" (one below) check the settings for amavis (second tab)
  3. customhost

    customhost New Member

    Policy is set to "Normal" with a score of 4.5.

    After further investigation, it seems like the instructions here and here helped to get the RBL blocklists checked at least for some spam mails. Still, they are not checked for all spam mails - some of them still do not include the respective headers.
  4. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    This is normal behavior, as a new wave of spam goes out it does not initially hit very many rbl's, hence less dns tests result in a score when first delivered, but by the time you check it again manually it has made it on a lot of them.
    Assuming by "headers" you mean the spamassassin rule names contributing to the message score, it's not that they were not checked, it's simply that the things which can be blacklisted from that message (ip addrs and domain names) weren't on the blacklists yet. (If you actually do mean the spam scanning headers are completely missing, that would be another issue.)
  5. customhost

    customhost New Member

    That makes sense, indeed. I never thought that way as when I checked the email manually just a few minutes later using SpamAssassin command line, it was on blacklists that were not listed in the SA rule names of the email header. But maybe those few minutes already make the difference then.
  6. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    They do. This is one point where greylisting can make quite an effect, if you can manage to get new waves of email to delayed even 5 minutes, the blacklists will catch a lot more of them. (The trick is how to do that, ie. what criteria to base the greylisting decision on (not as simplistic as postgrey) - I've used mtpolicyd for that on a non-ispconfig system with some luck; I believe rspamd can do greylisting as well, and I'm hoping it will be flexible enough to do this well, once I get a chance to look into it.)

Share This Page