On Fri, Dec 02, 2005 at 10:21:01AM +0100, Keith Dunnett wrote:
> > That or use reject_rbl_client with proper RBLs. That's actually the same
> >like
> >his idea, but _humanly_ verified (if it is a good RBL). I would very avoid
> >RBLs which use automatic mechanisms unless they are failproof. Spamtraps are
> >not.
> I respectfully disagree. Many human-managed blacklists are influenced by the
> politics of their owners and
> most take a 'guilty until proven innocent' approach. That is to say, they are
> free and easy about blocking
> addresses which were offensive a fortnight ago, unless and until the system
> admin gets in touch. Most of the
> time, this doesn't cause a problem, and I know that there are those who would
> vigorously defend this approach.
> But have you ever tried getting an innocent address removed from DSBL, for
> example?
That's why I made a note to "good RBL". Humanly in that sense, that it _is_
tried to verify whether some mail to a spamtrap or similiar is _no_ ISP or an
abused MTA (unless it's an open relay).
Automatic listing on a RBL will always result in a blocking of ISP X or Company
Y.
RBLs based on human decisions like "I don't like that network, or I don't have
a glue why a spam/virus came from the originating IP, and I don't know what the
originating IP is" are bad, yes.
However, we drift too far away.
Blocking client X via check_client_access should be done manually. That's work,
too, yes - but less work than maintaining whitelists of ISPs and parsing the
log for false positives.
A lot safer may be rejecting the received: bad origin in header_checks.
Because this wouldn't affect legitimate mails (if done properly). But then, lets
come to hotmail/msn and webmail. He quickly will block those services because
the originating IP is a hotmail/msn IP from the received: trace. He must
make sure, that his analyzer reads out an eventually X-Originating-IP: which
are set by hotmail/msn. And he must make sure, that this cannot be exploited
by sending him a spam/virus mail with a faked X-Originating-IP: IP header
which may then block the IP given by the attacker.
All in all, it is unsafe to do it automatically of any sort or requires too
much administrative and programming overhead.
--
Robert Felber (PGP: 896CF30B)
Munich, Germany
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
