on the contrary blocking ips at the firewall is the most effective approach. It minimizes the impact on your mail relay since tcp never gets to open the socket and access the application. This applies even if it is a dynamic IP. Your issue is permanent blocking. This is controversial. The idea has been to exert pressure on ISPs whose users complain. This is of limited success. the idea is that if dialup and dhcp (cable, dsl) users found they could not access major portions of the internet -- not just for e-mail but web browsing as well -- then they would be motivated to complain to their ISPs who would act more forcefully and quickly against spammers etc. . If somoene could get yahoo and hotmail and google to "sign on" to such a program then yes there would be a dramatic amount of complaints. Blocking ips at the application level , i.e. in your MTA, is proven effective in reducing spam. Forbidding dynamic IPs from talking to your mail relay, force them to go thru their ISP mail relay, is definitely good policy. Temporary, say 15 minute, blocking at the ip level at the border of your network for a spam/hack in progress is a good compromise that will cause the bad guy to look elsewhere. On Thu, 19 May 2005, D?rfler Andreas wrote:
in general blocking ips isnt the best and blocking dynamic ips is more then a stupid idea.
on another mailinglist someone wrote rules for spamassassin http://mailscanner.prolocation.net/german.cf. isnt a good idea to activate the rule forever but for a few weeks it will be ok
greetings andy
--free your mind, use open source http://www.mono-project.com
ASCII ribbon campaign ( ) - against HTML email X & vCards / \
-----Original Message----- From: Robert Schiele [mailto:rschiele@uni-mannheim.de] Sent: Thursday, May 19, 2005 6:15 AM
This list seems rather useless to me because most of these IPs are dial-ins and thus will change frequently.
Robert
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here