> From: Rob McEwen [mailto:[EMAIL PROTECTED] 
> In fact, a good example of positive solutions would be Herb 
> Martin's recent post about using Greylisting and RBLs 
> together where the message is not blocked outright based on 
> RBLs... but, rather, the RBL triggers the greylisting... that 
> was a great example of a good solution! This is the kind of 
> thing I'd like to talk about in this new thread.
> 
> Personally, I don't feel comfortable with Greylisting and 
> there are some disadvantages to greylisting that many admins 
> can't live with.

What makes you uncomfortable?  There really are only
two issues:

        1) Delay of legitimage email

        2) Broken legitimate servers that won't resend

Most greylist code (e.g., Python Greylistd) comes with
a whitelist of the very few servers that will suffer 
from #2 but notice what the use of RBL and such does:
it practically eliminates the need for this whitelist
TOO if you pick good drivers:  Since those broken servers
are also unlikely to suffer from RBL or other problems
(or else they would lose a lot of their own mail) it's
another way to cut down on problems.

So basically a non-issue (broken resend servers) with
Greylisting, becomes even less of an issue if you pick
good drivers.

As to #1, delays -- these are an issue with 'normal'
greylisting -- legitimate "first time IP/sender/rcpt"
email is delayed 15 minutes to a few hours.

But again, since almost no legitimate email is ever
greylisted only almost nothing DESIRABLE EVER gets 
delayed.  

Remember, we are only greylisting stuff that many 
(but not all) people would just REJECT.

Do you have any other concerns about greylisting?

I assure you the two above are irrelevant in practice
(but you should check for yourself too.)


> Therefore, I have another solution.

In reading your solution it seems like a lot of 
extra work or (script) complications to keep it up
when you don't need it.

> HERE IS MY SOLUTION:
> 
> (1) weigh the RBLs according to how FP safe they are (For 
> 
> (2) I also add points based on how many RBLs (weak or strong) 
> catch that sending server's IP. The idea here is that any one 
<snip>

> (3) Still, occasionally, a large ISP's legit mail server will 
<snip>
> But I found a solution here as well. I simply have done an 
> override on my caching DNS server where I nullify the lookups 
> for these RBLs. I base this on research I did lookups on 

It's simpler to just build another whitelist than override
the server (unless that is what you mean.)

--
Herb Martin

Reply via email to