289684Re: Initial 220 greeting timeout
- Nov 27, 2012On 11/27/2012 2:51 PM, Alex wrote:
> Stan,Dynamics are 95+% of what's listed in the PBL:
>>> Right, that makes sense. A spammer wouldn't have access to a
>>> consecutive block of dynamic IPs, like from a cable company or
>>> Verizon. It still could mean that it's listed in the PBL by now,
>> 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
> Yes, I didn't fully understand that dynamics aren't listed in the PBL.
I am an ISP. I don't want my dynamic/dial-up users sending spam via
infection. I contact Spamhaus and say "Please add this /16 to the PBL.
These IPs should never send direct SMTP mail." This is why it's called
the "Policy Block List". It's network owner policy that decides what is
listed. In some cases Spamhaus adds entries without being contacted by
network operators when it is clear a network is dynamic and bot spam is
The SBL is where you'll find snowshoe IPs listed by Spamhaus.
>>> I have fail2ban working with dnsblog. It may not necessarily work forDropping SMTP packets should be done with care. If you FP on an email
>>> snowshoe, but it works well for repeated attempts.
>> Fail2ban doesn't stop spam. It merely shifts the burden of rejection
>> from Postfix to the IP stack. And it won't work for snowshoe because
>> you're never going to detect snowshoe with Postscreen, or any Postfix
> I thought the IP layer would be more efficient than filtering it at
> the postfix application layer, and also would then not have to
> specifically worry about whether it was part of a snowshoe botnet or a
> single hacked IP.
to the CEO and he comes asking, giving you a sender address, you have no
way to track it down in logs. The CPU overhead of rejecting with
Postscreen or smtpd is absolutely tiny, especially compared to a run
through SA, and in the big picture is not much more than dropping
packets. Postfix rejections occur in a few microseconds to milliseconds
on modern hardware.
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
server and PCs behind the same NAT'd IP and don't do egress filtering on
TCP 25. If they get a bot infection and you autoban the NAT'd IP you're
now killing all their legit mail. Again, do SMTP packet dropping with
care. This means doing it manually for known bad hosts/networks. Or,
don't do it at all.
>>> Okay, I've set the postscreen threshold to 1, so any hit is a reject.Header checks aren't usually an overhead problem unless you have many
>>> It's already dramatically increased the number of rejects.
>> And decreased the load on your content filters as well, I presume, and
>> likely decreased or eliminated your 220 delay issue.
> Yes, I haven't seen any further indication of 220 delay issues. I also
> still have a few too many header checks that I'll be purging.
hundreds or thousands of them. Body checks are more of a concern.
Neither eat CPU anything like SA.
>>> I've also added the reject_rhsbl_reverse_client and other rhsblAgain, adding reject_rhsbl_foo_client adds no additional queries because
>>> statements you've recommended. I decided not to bother with
>>> warn_if_reject and trust the DNSBLs. I realize it's doing twice as
>>> many DNS lookups for now.
>> You're using SA which makes all of these same DNSBL lookups. So you're
>> not doing any extra lookups, just doing them sooner in the cycle. If
>> mail reaches SA its lookups are now local to your resolver, which speeds
>> up SA as it doesn't have to wait for remote DNS server responses.
> I meant that if I kept postscreen running, I would have the lookups there too.
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.
>>> I think I like postscreen better than the rhsbl statements because ofYou seem to be mistakenly looking at these sets of Postfix features as
>>> the additional features of postscreen.
>> Fuzzy dice hang'n on your mirror don't make the car go faster. If you
>> find that you *need* weighting of RHS domain rejection decisions due to
>> high FPs (which I doubt), then you can use postfwd or policyd for
>> weighting. Keep in mind policy servers are much slower than Postfix
>> smtpd restrictions, but faster than content filters. Thus it's always
>> best to reject with inbuilt Postfix restrictions if you can, on a busy
> I meant that postscreen has extra functionality such as the protocol
> tests before and after the 220 greeting.
competitive instead of cooperative. They are a layered defense, and
Postscreen is the point man. The features you mention here are
zombie/bot specific, and thus only exist in Postscreen. RHSBL tests
only appear in SMTPD. There is some feature overlap in Postscreen due
to user demand.
I think it would greatly benefit you to actually read the Postscreen
documentation which explains all of this in detail:
>> Prices should be a little lower by then as well, at least for the SSDs.Yes. You use the included 2.5 to 3.5 adapter clearly shown in the pictures.
>> The RAID card prices may not move much. SSD simply makes soo much
>> sense for a mail gateway. You never have to worry about a queue IO
>> bottleneck again.
> 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:
> http://www.newegg.com/Product/Product.aspx?Item=N82E16820167120Using the onboard Southbridge SATA controller and software vs hardware
> I thought I could use the existing SATA controller on board with the
> Linux md RAID5.
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
desire to use RAID5 baffles me, and likely most others here. Parity
RAID has ZERO upside and a long list of downsides for transactional
workloads. A single SSD gives you the IOPS and capacity you need. A
mirror adds redundancy.
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
(patches to fix this threading bottleneck have been submitted but won't
be available in distro kernels for many months to years).
Whether you do hardware or software RAID, do yourself a favor and use 2
mirrored SSDs. You can't need more than 60GB for a queue device, if
1/3rd of that. And you'll avoid many potential headaches of RAID5.
- << Previous post in topic Next post in topic >>