If you use sendmail, this is pretty trivial, its a slight modification to
the original RBL check :

# DNS based IP address spam lists
R$*                     $: $&{client_addr}
R$-.$-.$-.$-            $: $(host $4.$3.$2.$1.rbl.maps.vix.com. $:
$1.$2.$3.$4 $)
R$-.$-.$-.$-            $: $(host $4.$3.$2.$1.dul.maps.vix.com. $: OK $)
ROK                     $@ OK
R$+                     $#error $@ 5.7.1 $: "Mail from " $&{client_addr} "
refused by blackhole site rbl.maps.vix.com
 or dul.maps.vix.com"

the last three lines in my email are one line though ;)

this is in the rule :
check_relay in Ruleset 98

essentially after checking the one, if it passes the first (RBL) it then
checks it vs. the second (DUL) if it actually gets an address back... it
rejects the mail, with the message.

___________________________________________________________________________

Pat Lynch                                               [EMAIL PROTECTED]
                                                        [EMAIL PROTECTED]
Systems Administrator                                   Rush Networking
___________________________________________________________________________

On Fri, 24 Sep 1999, Rodney W. Grimes wrote:

> > >From: "Rodney W. Grimes" <[EMAIL PROTECTED]>
> > >Date: Fri, 24 Sep 1999 03:00:55 -0700 (PDT)
> > 
> > >Another thing that ISP coulds start doing (we are in process with
> > >this now, but on a monitoring only basis, instead of a deny we
> > >just log them) is to block all outbound from AS tcp 25 setup packets.
> > 
> > Not quite sure I follow this.
> 
> ipfw add 10250 allow     tcp from ${smtpsmarthost} to any 25 setup out via lnc1
> ipfw add 10259 allow log tcp from any to any 25 setup out via lnc1
> 
> This is placed on all AS border routers, anyone attempting to
> do direct port 25 outbound from our AS trips 10259 and gets to talk
> to me about what it is they are doing.
> 
> The comptete rules set is a fair bit more complicated than the above
> as we are also a transit AS and I have to allow the port 25 setup traffic
> from them to work correctly, so I can't just go make 10259 a deny at
> this time.
> > 
> > >This prevents your customers from being something that could get you
> > >on the RBL or the DUL MAP for bad behavior, it also inforces the use
> > >of your smart host relay, as it/they is/are the only way to get a
> > >tcp port 25 setup completed.
> > 
> > About the only positive thing I have to say about the DUL is that Vix
> > stated that entries are placed on it at the request of the custodians of
> > the netblock in question.
> 
> If that is the case then this is ideal.  Everyone should be using the
> DUL, as the maintainer of that IP space has specifically stated that
> they do not want or allow smtp setup connections from that IP space.
> 
> Thus by using the DUL you are simply helping a costodian implement
> the policy they have already layed down.
> 
> > 
> > >Do you know about the RBL?  How do you feel about it?  We are using
> > >it via DNS and BGP on a test basis right now.    I have had legitimate
> > >important mail blocked at Freebsd.org due to the source being on the
> > >RBL, but that is a price I am willing to pay.
> > 
> > I'm far more comfortable with the use of the RBL than the DUL.
> 
> Given what you stated above I don't see how you could favor the
> RBL over the DUL, the DUL is stated administrative policy, the RBL
> is a reactive to bad behavior and in opposition to stated administrative
> policy for almost every entry in it.  
> 
> > Indeed, my externally-visible home SMTP server uses the RBL (but not the
> > DUL).
> 
> You should probably run both.... I know I am going to go see what it
> takes to intergrate DUL into our current scheme of things.  And submit
> our IP dial up blocks for inclusion in the list.
> 
> -- 
> Rod Grimes - KD7CAX - (RWG25)                    [EMAIL PROTECTED]
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to