That being the case, then it wouldn't work if there were no external or internal dns servers listed but there was a host listed in the maps/rbl subsection of the email proxy service. Of course it does, but then that's what I've been saying since message one. I won't even try to figure out where the miscommunication lies or justify my position/experience/credibility when it comes to this topic. It's too bad there are guides on dns but few on maps/rbl, then I'd have a cool link too for the edumacation the masses. I do keep thinking of this link http://www.se7en-x.com/argue/
On Tue, 15 Oct 2002 14:20:07 -0400 (EDT), you wrote: > >> How do the configured DNS resolvers know to contact the rbl zones? >> Unless it's a stealth slave zone, doesn't seem they would know. I take > >They use the information contained in the request from the SMTP proxy, as >well as information gained from authorative servers for the TLDs. > >Please do some research on how the DNS system works, or see the URL that >explains this that I posted in a previous email. > >> it the current versions no longer have the section under email proxy for >> maps/rbl to specify the server to use? That's what is being implied. > >The current versions of the GNATBox software still have the option to >specify what RBLs to use for the SMTP proxy. The entries are used to >formulate the requests that are sent to the DNS resolver. > >> Here you imply that there is still a section under email proxy for >> maps/rbl but this doesn't jive unless you are paying to be a stealth >> slave zone with MAPS or other services that offer this. Since it would >> ask the server(s) configured in that section not the external or >> internal dns. Dnsbl maps type systems and domain name lookups are >> seperate. > >There are more options then just running a stealth slave zone. Some >blacklists do (or did a few years back...I don't have current experience >with those lists.) require that you mirror a copy of their zone and make >all requests of that mirror. (ie: stealth slave zone) > >In that case, the recursive server should contain pointers to the >authorative slave server that contains this zone, since you do not want to >use the regular authorative servers. > >With dnscache, this would be done by adding a file in >/service/dnscache/root/servers with the name of the zone. The file would >contain the IP address of the server that you wish to contact. This would >override the normal recursive lookups.) > > >Most current publicly-accessable RBLs do not require (and in many cases do >not allow) you to transfer a copy of the zone to your authorative servers. >(a "stealth slave zone", if I understand what you mean by that term.) >Instead, they prefer that you do normal recursive lookups using their >servers as authoritative. (that is, the standard DNS lookup routines.) > >The SMTP proxy is configured with the subdomain of the RBL. The proxy >then formulates a request to the RBL based on the source IP address of the >connection. The request is sent to the resolver, who handles it from that >point. If the resolver returns any A record, the SMTP proxy will then >request a TXT record. If the TXT record exists, this will be used in the >error message to the client (and the logs) > > >> Ahem... If it did look in /etc/resolv.conf then there would be no need >> for this line in sendmail v8.8 >> R$-.$-.$-.$- $(host $4.$3.$2.$1.blackholes.mail-abuse.org. $:OK $) >> or under M4 compatible versions >> FEATURE(dnsbl, `blackholes.mail-abuse.org', `Mail refused')dnl > >Yes, there would. The "host" line is actually a unix command. This >command is then using the systems resolvers to resolve the request. > >ie: > >why:/root%# host 2.0.0.127.spews.relays.osirusoft.com >2.0.0.127.spews.relays.osirusoft.com has address 127.0.0.4 > >If your prefered RBL used a different format, you'd be able to create a >differently formated "host" line to make the request. > >The feature you cite only configures the zone that the RBL lookup should >use in the DNS requests, it does not tell sendmail WHO to contact...the >resolver and standard DNS routines take care of that. > > >> Since we are on the topic of caching/lookups and maps, according to >> mail-abuse.org >> >> "In no case ought you cache the results of a MAPS RBLSM lookup, since a >> blackholed host can right itself and be removed in a matter of seconds." > >Probably a good idea. The authorative server should set a low enough TTL >to prevent caching in most cases. (some recursive servers are configured >to ignore the TTL and use a standard cache time instead. AOL does this, >for instance.) > >> Also, direct usage via DNS with a mail transfer agent (either sendmail >> or another, which the smtp proxy qualifies as) and subscription via DNS >> are seperate. > >Agreed, though the "direct usage" does not mean (necessarily) that the MTA >(sendmail or the GNATBox SMTP Proxy) is making the request directly to the >MAPS servers. It only means that the MAPS servers are the eventual target >of the query. The recursive resolvers make the actual direct request to >to the authorative servers for the zone. > > >> RRset of the zone, so they will never be targets of third party MAPS >> RBLSM (DNS) queries. In order to cause such servers to be queried by >> your mail relays, you must configure the recursive name servers listed >> in your resolv.conf files as zone slaves. (It is normally a bad idea to >> mix authoritative and nonauthoritative data in the same name server, but >> this is a specified exception to that rule.)" > >This quote is very BIND-centric, but accurate. It applies directly to >the GNATBox SMTP proxy, if you choose to be a MAPS secondary server. >You'll need to configure you recursive resolvers to get their data from >the server that contains a copy of the MAPS zone. > > > >--- >David Raistrick > Systems Administrator - Global Technology Associates, Inc > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] To subscribe to the digest version first unsubscribe, then e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Archive of the last 1000 messages: http://www.mail-archive.com/[email protected]
