Loading ...
Sorry, an error occurred while loading the content.

Re: Initial 220 greeting timeout

Expand Messages
  • Stan Hoeppner
    ... You re welcome. I understand that completely. No, not at all. ... Yeah, with fail2ban you don t really have no audit trail at all. Keep in mind that
    Message 1 of 15 , Dec 3, 2012
      On 12/2/2012 1:20 PM, Alex wrote:

      > Thanks for the explanation. Trying to do too many things at once. You
      > probably think I'm an idiot by now.

      You're welcome. I understand that completely. No, not at all.

      >> 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.

      Yeah, with fail2ban you don't really have no audit trail at all. Keep
      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 be
      > blacklisted, of course.

      See above.

      > 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.

      This is a double edged sword: if you hit with header_checks you save SA
      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't
      > that two queries for the same rhsbl entry?

      When I say "query" I'm talking about those that come with cost, i.e.
      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 about
      > reject_rhsbl statements, and forgetting they're domain, not IP based.

      Yes, postscreen has but a fraction of the rejection parameters/types
      available in SMTPD. All of the domain based rejections are SMTPD only.

      > 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.

      Don't do that. Send me the make/model# and/or a picture of link to the
      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 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.

      There's nothing inherently wrong with mdraid. As long as one knows its
      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.
      > 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.

      And this is one of the disadvantages of mdraid in absence of a BBWC
      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
      FS corruption.

      > 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.

      With SSD if you use anything other than 2 drive mirroring (RAID1) you're
      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.

    Your message has been successfully submitted and would be delivered to recipients shortly.