Bug 6613 - SORBS DNSBL - Result codes ending .11 and .12
Summary: SORBS DNSBL - Result codes ending .11 and .12
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.3.2
Hardware: All All
: P5 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
Whiteboard: Needs 2 votes for sandbox of net rule
Depends on:
Reported: 2011-06-01 19:06 UTC by D. Stussy
Modified: 2012-01-18 22:50 UTC (History)
3 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 D. Stussy 2011-06-01 19:06:35 UTC
Since we're already using the SORBS DNSBL combined zone, would it hurt to add rules for the following result codes?  I couldn't find any prior discussion regarding them:


badconf.rhsbl.sorbs.net - List of domain names where the A or MX
                          records point to bad address space.
 nomail.rhsbl.sorbs.net - List of domain names where the owners have
                          indicated no email should ever originate from these

Has anyone tested the usefulness of these response codes yet?
Comment 1 Darxus 2011-06-03 18:41:37 UTC

That is kind of unclear, but rhsbl.sorbs.net is for querying hostnames, and dnsbl.sorbs.net is for IPs, so we're not already querying a zone containing this data.  But these should at least be added to somebody's sandbox for evaluation.

I believe the rules should be:

header   __FROM_SORBS_RHSBL  eval:check_rbl_envfrom('sorbs_rhsbl', 'rhsbl.sorbs.net.')
tflags   __FROM_SORBS_RHSBL  net

header   FROM_SORBS_BADCONF  eval:check_rbl_sub('sorbs_rhsbl', '')
describe FROM_SORBS_BADCONF  Envelope sender is in badconf.rhsbl.sorbs.net
tflags   FROM_SORBS_BADCONF  net
score    FROM_SORBS_BADCONF  0.001

header   FROM_SORBS_NOMAIL   eval:check_rbl_sub('sorbs_rhsbl', '')
describe FROM_SORBS_NOMAIL   Envelope sender is in nomail.rhsbl.sorbs.net
tflags   FROM_SORBS_NOMAIL   net
score    FROM_SORBS_NOMAIL   0.001

I have low expectations for badconf.rhsbl.sorbs.net, because it sounds possibly identical to bogusmx.rfc-ignorant.org for which we recently killed the DNS_FROM_RFC_BOGUSMX rule because it sucked (bug 6526).

Is this enough to get a "[review]" in this bug's summary?  Or should I create a patch to create myself a sandbox for somebody else to commit?
Comment 2 D. Stussy 2011-06-03 19:15:08 UTC
If that were true, they shouldn't be listed with the OTHER return codes which come back for query by IP.  SORBS needs to re-write their page to make such clear if what you say (query by domain) is the case.

The way I read their list of RC's as presented is that it's POSSIBLE to return these codes (.11 and .12) in response to a request by IP, as they are part of the list where all other responses are query by IP.  Therefore, my question.
Comment 3 Darxus 2011-06-03 19:44:03 UTC
I don't know anything that isn't on that page.  I agree that either way, it's unclear.  I sent a message via their contact form requesting clarification.
Comment 4 Darxus 2011-06-03 19:53:19 UTC
It would be fun if we had the ability to do something like:

header RCVD_IN_SORBS_UNHANDLED       eval:check_rbl_uhandled('sorbs')
describe RCVD_IN_SORBS_UNHANDLED     SORBS: RBL returned unhandled value <value>

That hit whenever none of the check_rbl_sub()s for a given RBL hit.
Comment 5 D. Stussy 2011-06-03 20:39:19 UTC
eval:check_rbl_uhandled is an interesting idea, especially for "mass checks" as it could alert us to the deployment of a new kind of entry (or result code) in these "combined" DNS databases.  I assume such would require:

1)  An A-RR that is affirmatively returned (so as to exclude timeout, etc.), and
2)  A flag being [re-]set when another check_rbl_sub matches.

We would have to guarentee that _unhandled() runs AFTER all _sub()s (or at least, after at least one sub which matches).

Currently, this could be simulated with a meta rule [per DNS list]; correct?
Comment 6 Darxus 2011-06-11 16:34:29 UTC
(In reply to comment #3)
> I don't know anything that isn't on that page.  I agree that either way, it's
> unclear.  I sent a message via their contact form requesting clarification.

Got a response from SORBS:

> Thank you for contacting us.
> Please provide the listed IP address so I can investigate this further
> for you.

I wish I had the exact text I sent them 8 days ago.  But they at least quoted the subject:  "RHSBL support - SpamAssassin contributor".  So yeah, their response, 8 days later, was impressively unrelated to what I asked them.

I do not recommend attempting to communicate with them via general@support.sorbs.net or their web form that does not require logging in.  It looks like the only real option is to create an account, log in, and find some other contact form.  Which I'm not currently in the mood to do.
Comment 7 D. Stussy 2011-06-12 00:16:08 UTC
Today, I posted a related query to this issue on Usenet's news.admin.net-abuse.email group.  Let's see if anyone knows.
Comment 8 D. Stussy 2011-06-12 23:12:40 UTC
Well, I got an answer - from "Michelle Sullivan" (the SORBS' operator pseudonym):

IP addresses will not result in any positive lookup.  Domain names only.

Therefore, we don't have to worry about these for the IP-based lookups.

Not closing the bug in case the RHSBL rules in comment 1 should be implemented (in masscheck or not).
Comment 10 Kevin A. McGrail 2012-01-18 22:50:49 UTC
I personally use checking of valid MX's as a very effective anti-spam tool.

This list has merit.  I believe we need a vote to add a net rule to a sandbox.  I'm +1 to try the rules from Comment 1.