|Summary:||SORBS DNSBL - Result codes ending .11 and .12|
|Product:||Spamassassin||Reporter:||D. Stussy <software+spamassassin>|
|Component:||Rules||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Severity:||enhancement||CC:||Darxus, kmcgrail, software+spamassassin|
|Whiteboard:||Needs 2 votes for sandbox of net rule|
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 127.0.0.11 nomail.rhsbl.sorbs.net 127.0.0.12 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 domains. Has anyone tested the usefulness of these response codes yet?
Comment 1 Darxus 2011-06-03 18:41:37 UTC
http://www.sorbs.net/using.shtml 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', '127.0.0.11') 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', '127.0.0.12') 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 email@example.com 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).