On Fri, 2006-02-17 at 21:13 -0500, CodeHeads wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Fri, February 17, 2006 9:05 pm, Craig White wrote: > > On Fri, 2006-02-17 at 20:54 -0500, CodeHeads wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> Hello all, > >> Have a question: > >> Would it be better to block IP's instead of domains for an email server? > >> > >> I guess would be that the person can change the domain in their reply > >> email address, so blocking IP ranges would be better, wouldn't it?? > >> > >> Example: > >> IP range = 222.168.0.0 - 222.169.255.255 (Actual spammer IP) > >> > >> Wouldn't be better to place the IP's in iptables?? Or would another > >> option > >> be better? > >> > >> I hope this was not discussed at a later date. Just curious on what the > >> IT > >> fields thinks of this. :) > > ---- > > Sure - use a hammer when the task at hand calls for a screwdriver. It's > > your mail server so use the hammer if that pleases you. That won't > > however stop the next ip range from sending you spam. > > > > Configure the mail server properly... > > greylist > > MTA with good RBL settings > > wrapper program [MailScanner | Mime-Defang | Amavisd-new] > > wrapper to control spamassassin & anti-virus (i.e. clamav) > > > > spam would be minimal > > > > Craig > > > > fwiw, I would recommend postfix/mailscanner/clamav/postgrey but other > > qualified opinions would recommend other things > > > Craig, > I am running the following: > Qmail, qmail-scanner, ClamAV, Spamassassin, maildrop. I should have posted > that in the first email. :) > > I will search on google for greylisting setup but is there a how to for > setting up grey listing on qmail?? Sorry, just learning the linux mail > server stuff. > > Thanks for the advice! :) ---- probably a good thing you didn't post that to the list as contentious as it is the last few days or we would have had a lot of people do the 'oh don't use Qmail' thing. On second thought...I am gonna post this to the list because some of these issues are worthy of discussion. To be honest...I don't know about Qmail - and greylisting is very much tied to the MTA that you use so the best thing to do if you want to implement greylist would be to use Qmail resources (lists/forums/whatever). You probably should implement some RBL's in Qmail and I wouldn't know how to do that either - I can get them installed in Sendmail but I have pretty much abandoned Sendmail these days for Postfix which seem to be the ultimate in configuration options. You can implement RBL's within spamassassin/qmail-scanner I think but by that time, it's too late as you have already received the mail. Over the past 2 years, I have migrated my setup to be very heavy on qualifying what I accept at the MTA level... the first thing is greylisting which simply defers original mail delivery based upon what are knows as tuples... sender/senders smtp server/recipient - the first time this exact combination occurs on an inbound mail, the local MTA sends back a TEMP FAIL error, which tells the sending SMTP connection to try again soon. If the SMTP connection is truly a SMTP server, it will queue the message for delivery in another 15 minutes or so. If it is a system corrupted by some worm or hacker and just spitting out email, it isn't going to store these messages and try later, it's just going to move on. The second level of defense I employ is delivery restrictions on a wide variety of things such as RBL's, reverse DNS verifiable SMTP server, mail to an actual account on my box. Between these two layers, I have knocked out a tremendous amount of inbound email that I have refused to accept. Then it is passed to a wrapper (I use MailScanner) which is put through spamassassin, clamav and a wide variety of scanning for phishing fraud, objectionable attachments, etc. - all controlled by the wrapper. At that point, email that gets through is delivered locally. Emails that score 6 -> 14 on spamassassin are put into users INBOX.SPAMBOX by sieve scripts that are automatically installed for each user as his mailbox is created. High scoring spam mail are simply filed in the giant bit bucket in the sky. This provides protection for false positives (for which I see very few but I did have this client who had some chick sending him all HTML mails from a hotmail account using a dial-up and that would be enough to get her into the 6 - 7 range in spamassassin so I finally just whitelisted her. One of the more amusing things about all this is that after I have implemented this type of setup for a client, 2 of them have called me worrying that their email isn't working because they weren't getting any spam and in a twisted sense, people now expect spam in their inbox and if they don't see spam in their inbox, they worry that their email system is broken. I hope this helps someone. Personally, I wouldn't recommend Qmail as some of these options are awkward to implement not to mention that Qmail stuff simply isn't GPL and therefore flies in the face of the best things that Linux can offer. Craig