Bug 6729 - SA could use a tool to help admins configure network based tests
Summary: SA could use a tool to help admins configure network based tests
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Tools (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: PC Windows 7
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-15 12:58 UTC by Kevin A. McGrail
Modified: 2017-02-04 14:23 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin A. McGrail 2011-12-15 12:58:39 UTC
The product could be compile-time such as this idea submitted by DFS of Roaring Penguin:

$ perl Makefile.PL
[...]

The following RBLs have certain usage restrictions.  Would you like to
enable them?  If unsure, say Y.  (Y/N): [Y]
[... a list of RBLs, preferably with links to their policy pages ...]

so that at installation time, SA users are at least aware of the issues.

For package maintainers, you'd want a noninteractive way to build SpamAssassin
and then a post-install configuration script that asks the RBL question.
(This is easily done on Debian; not so easy with RPM-based systems that
don't allow interaction during installation.)


- or -


Something like Martin Gregorie's idea:

...it won't work for the package installs that I and, at a guess, a
lot of small installations use. I run the Fedora distro, and so the
version of SA I'm running is that installed and periodically updated by
yum.

I like the idea of the tool though, particularly if it can link to
descriptions of each RBL and, hopefully, to the masscheck results for
it. From my POV a post-install tool, and especially one that can be
re-run periodically, would be a lot more useful.


This may cross-over to the idea to disable queries as discussed in bug 6724 as split into bug 6728 and a way to list the rules that should be disabled for a DNSBL.
Comment 1 Kevin A. McGrail 2011-12-20 16:43:19 UTC
More notes:

Based on Bug 6142, to disable uribl, you need to use

skip_uribl_checks 1 to disable the URIDNSBL plugin

And there might be a skip_rbl_checks config option as well that gives some good ground work for this bug.
Comment 2 Joe Quinn 2017-02-04 14:23:27 UTC
This tool should also run a test query through the machine's DNS to see if it will hit URIBL_BLOCKED. This is probably the single most frequently asked question on users@.

I suggest querying test.uribl.com.multi.uribl.com (a documented testpoint per http://uribl.com/about.shtml). If it comes up 127.0.0.1, the current setup will be blocked. If it comes up 127.0.0.14, the current setup will most likely not be blocked.

For a nicer error message, we can also do a PTR lookup of the nameserver being resolved. If I ran the tool on my home system, it might say:

Your current nameserver at router.manufacturer.com (192.168.1.1) will be unable to perform most RBL lookups due to rate limiting. Make sure you are not using a public nameserver, or your ISP's nameserver. Also make sure your current nameserver is not forwarding to one of these.

The SpamAssassin project recommends setting up your own local caching nameserver. For information on how to set one up, see https://wiki.apache.org/spamassassin/CachingNameserver