Hi, >>> Again, the IP in question will never be listed in the PBL. SBL maybe, >>> PBL no. Might be time to brush up on Spamhaus various lists and their >>> criteria. >> >> Yes, I didn't fully understand that dynamics aren't listed in the PBL. ... > The SBL is where you'll find snowshoe IPs listed by Spamhaus.
Thanks for the explanation. Trying to do too many things at once. You probably think I'm an idiot by now. > Dropping SMTP packets should be done with care. If you FP on an email > to the CEO and he comes asking, giving you a sender address, you have no I meant as it relates to blocking by spamhaus or barracuda. From an FP perspective, that doesn't affect it either way. Perhaps the audit trail is a little better with just letting postscreen continue to block it rather than fail2ban, however. > If you're going to drop packets make sure you know the IP send nothing > but spam. Case in point, many SOHOs and small biz have their Exchange Yes, I'm only using it on IPs that have already been confirmed to be blacklisted, of course. > care. This means doing it manually for known bad hosts/networks. Or, > don't do it at all. I've got stories to tell there. Another day, though. > Header checks aren't usually an overhead problem unless you have many > hundreds or thousands of them. Body checks are more of a concern. > Neither eat CPU anything like SA. I'd say I had a few hundred. Dumped some of the old ones, and had them there instead of SA for just that reason. >> I meant that if I kept postscreen running, I would have the lookups there >> too. > > Again, adding reject_rhsbl_foo_client adds no additional queries because > you are using Spamassassin, which also performs these same queries. The > dnsbl queries you are doing in Postscreen are also duplicated by SA. So > again, you have no additional net queries. Assuming the rhsbl fails in postfix, then SA processes it, doesn't that two queries for the same rhsbl entry? > I think it would greatly benefit you to actually read the Postscreen > documentation which explains all of this in detail: > http://www.postfix.org/POSTSCREEN_README.html I've read it again, but my confusion was with reading about reject_rhsbl statements, and forgetting they're domain, not IP based. >> I've actually given more thought to doing this sooner on the secondary >> box. However, I can't find any 3.5" SSD SATA disks that will fit in my >> existing 1U SATA chassis. Any ideas? Here's the newegg link you sent: > > Yes. You use the included 2.5 to 3.5 adapter clearly shown in the pictures. Unfortunately it's not that easy. You would think it would be that easy, but somehow I knew there would be complications. I investigated this, and it's just a tray to make it fit in a 3.5" bay, such what you'd find in a desktop PC. Looking at the picture, it just didn't seem right. I actually called Intel, and I explained to them I had a 1U chassis and needed to be able to put this 2.5" disk in the tray where normally a 3.5" disk is used. He told me what you thought -- that the tray would work for that, even though I knew there was no way it would. I ordered two of the 60GB 520 series disks instead of the ones you mentioned -- better warranty and faster. They arrived on Friday, and sure enough, it's just a metal frame to put it in a desktop, not a 1U chassis. So, considering they generate no heat and take up no space, I'm thinking of using velco inside the case. We'll see how that goes. > Using the onboard Southbridge SATA controller and software vs hardware > RAID is up to you. I prefer hardware RAID solutions for many reasons > that have been covered by myself and others many times. Either way your I would never use the onboard SATA controller. That's crap. I have great faith in Neil Brown and his md code :-) I've lost a few software arrays over the years, but have always found them reliable and better supported in Linux. I've also used the battery-backed hardware RAID in the past, which is nice too. > Using RAID5 simply adds the cost of a 3rd drive, slows down your IO due > to RMW cycles, increases initialization and rebuild time, etc, etc. And > with md/RAID5, a sufficiently high IO rate on only 3 SSDs can eat one > entire CPU core in overhead because the writer is a single kernel thread Yes, there's no debating an SSD would be preferred in all situations. When this was built, we used four SATA3 disks with 64MB cache and RAID5 because the system was so fast already that the extra expense wasn't necessary. I also wasn't as familiar and hadn't as extensively tested the RAID10 config, but will sure use it for the mailstore system I'm building next. Thanks again, Alex
