>That gets back to one of my earlier points, which is you want to have
>management buy-in that there will be some mail rejected that you want to
>recieve. We made the decision that the trade-off was worth it.
server- or gateway-level anti-abuse filtering is always worth. Letting
that crap get to the desktop is dangerous and inefficient.
>We've had customer systems show up on ORDB for having an open relay. Thats
>pretty well defined and pretty easy to fix. The problem is that something
>like a SpamCop listing is much harder to resolve. This is the reason the
>GnatBox really needs a whitelist to overide the DNSBL listings when you
>cant fix the problem in a timely way.
Sure, it would be very difficult and painful, next to impossible, to run a
mail-filtering function that only had black-list capability, esp when
subscribing to external black lists like RBL servers where getting unlisted
can be sticky. With a whitelist, it's painless to except an "important"
MTA that is listed in a RBL.
Mail doesn't get "lost" or destroyed, it gets rejected, bounced back to the
("important") sender who should then figure out why, from the reject
reason, why they mail is unacceptable.
For serious, flexible anti-abuse filtering, one would have to go with a
dedicated MTA (postfix is my recommendation) vs a packet filter box or
proxy box with SMTP tack-ons. eg, PIX is famous for its broken, non-ESMTP
"fix up" of SMTP.
Len
www.menandmice.com/DNS-training : DNS Training
BIND8NT.MEIway.com : ISC BIND for NT4 & W2K
IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways
---------------------------------------------------------------------
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]