[SURBL-Discuss] RFC: SURBL software implemetation guidelines

Jeff Chan jeffc at surbl.org
Sun Oct 31 14:13:10 CET 2004


I've updated the SURBL Implementation Guidelines page slightly:

  http://www.surbl.org/implementation.html

> Implementation Guidelines

> Here are some very brief guidelines for folks writing software
> to use SURBL lists: Your code should: 
> 
>    1. Extract URIs from message bodies. (Extraction of URIs
> from message bodies should ideally include full resolution of
> redirections into the final target domain name. This can be a
> non-trivial problem.) 
>    2. Extract base (registrar) domains from those URIs. This
> includes removing any and all leading host names, subdomains,
> www., randomized subdomains, etc. In order to determine the
> base domain it may be necessary to use a table of country code
> TLDs (ccTLDs) such as the partially-imcomplete one SURBL uses. 
>    3. Not do name resolution on the domains.
>    4. 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. A non-result
> indicates lack of inclusion in the list. A result of 127.0.0.2
> represents inclusion, i.e., probable spam. 
>    5. 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. 
> 
> SURBL lists unusually have both names and numbers in the same
> list. For example, 2.0.0.127 and test.surbl.org and similar
> actual spam domains and addresses are both in all SURBL lists.
> Numbered addresses in SURBLs should have occurred in spams as
> numbers, e.g.: literally http://1.2.3.4/.  

Would still like comments about anything I may have left out
or anything else before I announce it.

Thanks,

Jeff C.



More information about the Discuss mailing list