On Monday, April 19, 2004, 5:32:32 PM, Devin Carraway wrote:
Two suggestions:
On Mon, Apr 19, 2004 at 04:52:03PM -0700, Jeff Chan wrote:
- Look up the domain name in the SURBL by prepending it to
the name of the SURBL, e.g., domainundertest.com.sc.surbl.org, then doing Address record DNS resolution on the resulting combined name. A non-result indicates lack of inclusion in the list. A result of 127.0.0.2 represents inclusion, i.e., probable spam.
I suggest you clarify the record type(s) that should be looked up, and what the necessary/sufficient conditions are for considering a response a positive match. For example, some DNSBL client implementations only look for a TXT record, to obtain a useful explanation they can report in an error. Is that sufficient for a positive? Is an A record containing 127.0.0.2 necessary?
- Handle numeric IPs in URIs similarly, but reverse the octet
ordering before comparison against the RBL. This is standard practice for RBLs. For example, http://1.2.3.4/ is checked as 4.3.2.1.sc.surbl.org.
Here you might want to stipulate that IPv4 octets should be looked up in their base-10 representation.
Thanks for the excellent suggestions Darren. I've updated as follows:
- Look up the domain name in the SURBL by prepending it to the
name of the SURBL, e.g., domainundertest.com.sc.surbl.org, then doing Address (A) record DNS resolution on the resulting combined name. A non-result indicates lack of inclusion in the list. A result of 127.0.0.2 represents inclusion, i.e., probable spam. SURBL matches also have a TXT record associated with them containing a descriptive reason for list inclusion, but the A record is the preferred query.
- Handle numeric IPs in URIs similarly, but reverse the octet
ordering before comparison against the RBL. This is standard practice for RBLs. For example, http://1.2.3.4/ is checked as 4.3.2.1.sc.surbl.org. Numeric addresses should be in base-10 representation.
How does that look?
Jeff C.