Re: Initial 220 greeting timeout
- On 12/2/2012 1:20 PM, Alex wrote:
> Thanks for the explanation. Trying to do too many things at once. YouYou're welcome. I understand that completely. No, not at all.
> probably think I'm an idiot by now.
>> Dropping SMTP packets should be done with care. If you FP on an emailYeah, with fail2ban you don't really have no audit trail at all. Keep
>> 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.
in mind that legit senders can wind up on trap driven lists. Both Zen
and BRBL expire listings when the IPs are no longer emitting for X
period of time. So if you feed DNSBL rejected IPs to it you should set
some kind of expiry period.
> Yes, I'm only using it on IPs that have already been confirmed to beSee above.
> blacklisted, of course.
> I'd say I had a few hundred. Dumped some of the old ones, and had themThis is a double edged sword: if you hit with header_checks you save SA
> there instead of SA for just that reason.
CPU time. If you miss you've added extra CPU time on top of SA. But
given you have a 4 core machine, IIRC, CPU shouldn't be much concern,
even with the relatively high msg rate you have.
> Assuming the rhsbl fails in postfix, then SA processes it, doesn'tWhen I say "query" I'm talking about those that come with cost, i.e.
> that two queries for the same rhsbl entry?
external to your network, with latency. The 2nd DNS query in this case,
SA, is answered by your local caching resolver, thus no cost.
> I've read it again, but my confusion was with reading aboutYes, postscreen has but a fraction of the rejection parameters/types
> reject_rhsbl statements, and forgetting they're domain, not IP based.
available in SMTPD. All of the domain based rejections are SMTPD only.
> Unfortunately it's not that easy. You would think it would be thatDon't do that. Send me the make/model# and/or a picture of link to the
> 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
> 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.
manufacturer product page. Is this a tier one chassis? I.e. HP, Dell,
IBM, etc? Once I see the drive cage arrangement I can point you to
exactly what you need. However, if the chassis has hot swap 3.5" SATA
bays then the adapter should allow you mount the SSD in the carrier with
perfect interface mating to the backplane.
> I would never use the onboard SATA controller. That's crap.Not all of them are crap. Many yes, but not all. This depends a bit on
what capabilities you need. If you don't need expander or PMP support
the list of decent ones is larger. If your board has an integrated
LSISAS 1064/68/78 or 2008/2108 then you're golden for mdraid.
> I have great faith in Neil Brown and his md code :-) I've lost a fewThere's nothing inherently wrong with mdraid. As long as one knows its
> 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.
limitations and works around them, or doesn't have a configuration or
workload that will bump into said limitations, then you should be fine.
> Yes, there's no debating an SSD would be preferred in all situations.And this is one of the disadvantages of mdraid in absence of a BBWC
> 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.
controller. For filesystem and data safety, drive caches should never
be enabled, which murders mdraid write performance, especially RAID5/6.
If your UPS burps, or with some kernel panic/crash scenarios, you lose
the contents of the write cache in the drives, possibly resulting in
filesystem corruption and lost data. Mounting a filesystem with write
barriers enabled helps a bit. If you use a BBWC controller you only
lose what's in flight in the Linux buffer cache. In this case, with a
journaling FS, the filesystem won't be corrupted. With mdraid, vanilla
controller, and drive caches enabled, you'll almost certainly get some
> I also wasn't as familiar and hadn't as extensively tested the RAID10With SSD if you use anything other than 2 drive mirroring (RAID1) you're
> config, but will sure use it for the mailstore system I'm building
wasting money and needlessly increasing overhead, unless you need more
capacity than a mirror pair provides. In that case you'd concatenate
mirror pairs as this method is infinitely expandable, whereas mdraid0/10
cannot be expanded, and concat gives better random IO performance than
striping for small file (mail) workloads. Note these comments are SSD
specific and filesystem agnostic.
The concat of mirrors only yields high performance with rust if you're
using XFS, and have precisely calculated allocation group size and
number of allocation groups so that each is wholly contained on a single
mirror pair. This XFS concat setup is a bit of a black art. If you
want to know more about it I can instruct you off list.
Now if you're using rust, as in a mail store where SSD is cost
prohibitive given capacity needs, then a properly configured RAID10 is
generally the best option for most people (and with any FS other than
XFS). It gives the best random write performance, good random read
performance, and far lower rebuild time than parity arrays. Most people
don't appreciate this last point until they have to rebuild, say, an 8x
7.2K 1TB drive RAID6 array on a busy production mail store server and it
takes half a day or longer, increasing latency for all users. With a
concat of mirrors and XFS, when rebuilding a failed drive, only those
users whose mailboxes reside on that mirror pair will have increased
latency, because this setup automatically spreads all mailboxes
relatively evenly across all mirrors. Think of it as file level
striping across disks, or more correctly, directory level striping.
Such a setup is perfect for maildir mailboxes or Dovecot m/dbox.