[Couple of extra recipients added of interested parties who are not on
exim lists]
The best specification of the variations found in the ORBS RBL type
list at present appears to be in
http://www.rahul.net/dhesi/orbs.faq.txt
[Working on the assumption that people pretty much know what RBL
handling is - at least at the basic level]
Basically each RBL lookup is performed by taking the reversed IP
address, appending the RBL domain and looking this up in the DNS. So
if you are using ORBS and looking up 127.0.0.2 (a test case) you would
lookup 2.0.0.127.relays.orbs.org, ie
> dig 2.0.0.127.relays.orbs.org any
;; ANSWER SECTION:
2.0.0.127.relays.orbs.org. 6d23h59m25s IN A 127.0.0.2
2.0.0.127.relays.orbs.org. 6d23h59m46s IN TXT \
"See http://www.orbs.org/blocked.cgi. Your mailserver \
is in the ORBS database. Consult with your mailserver \
administrator."
[answer both reformatted, and a specific a and txt query done
previously which primed the cache]
For each valid RBL entry there is an A record and optionally (but
currently always) a TXT entry - the TXT entry is currently used to
provide a error/warning message.
The ORBS enhancements involve using different A record values to denote
different forms of "sinner" in the database - ie confirmed open relay
(127.0.0.2), a manual entry (127.0.0.3) or a netblock - the politically
hot one (127.0.0.4).
There is also potentially a "white list" - an RBL like list of
(probably single host) exceptions to large netblocks.
I think we can handle these extensions to the current RBL handling with
a few (backward compatible) changes. The current format of rbl_domains
is a colon separated list of rbl domain entries, where each rbl domain
consists of a domain optionally followed by /warn or /reject:-
RBL_DOMAINS = RBLDOM [ : RBL_DOMAINS ]
RBLDOM = domain [ /warn | /reject ]
I'd like to change this to
RBLDOM = domain [ = ipaddr[,ipaddr...] ] [ /warn | /reject | /accept ]
The domain is the domain suffix to use for the RBL lookup, and an A/TXT
lookup is done in the DNS (if there are no A records for that entry
then you do not also lookup the TXT records).
if there are is an =ipaddr... section to the RBLDOM entry then the
returned A records should be compared to each of the comma separated IP
addresses in turn, and the RBLDOM entry only taken as matching iff one
of those ip addresses match.
if there is no =ipaddr section to the RBLDOM entry then any A record is
taken as a match.
[I originally thought of using regexps here rather than IP lists, but
the dots in ip addresses mean regexps need lots of backslashes and
hence the admin gets a headache]
The suffix then determines the way the lookup is handled - this
defaults as per the current exim implementation. The values are:-
/reject - reject the any recipients given by RCPT SMTP commands
except those listed in recipients_reject_except.
[accepted recipients have a warning header added to the
message]
no further rbl_domains entries are parsed (ie this short
circuits evaluation of rbl_domains)
/accept - accept any recipients given by RCPT SMTP commands
no further rbl_domains entries are parsed (ie this short
circuits evaluation of rbl_domains). This is used for
"white lists". Earlier /warn entries may have already
added warn headers - ordering within the rbl_domains
should be used if this is a problem.
/warn - accept the recipients, but add a warning header to
the message. Further rbl_domains entries are also
processed***
*** This is the current exim implementation. I am wondering if this is
worth doing or whether we just say first hit wins, no more rbl_domains
are processed whether its /warn, /accept or /reject.
How does this sound to people....?
Nigel.
--
[ - Opinions expressed are personal and may not be shared by VData - ]
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ Phone: +44 1423 850000 Fax +44 1423 858866 ]
