Re: [PLUG] Postscreen (another tool for helping to minimize the effect of spam)

[ac <ac@main.me>]

On Mon, 24 Oct 2016 16:47:38 -0400
Rich Freeman <r-plug@thefreemanclan.net> wrote:
> On Mon, Oct 24, 2016 at 4:36 PM, ac <ac@main.me> wrote:
> > On Mon, 24 Oct 2016 16:25:18 -0400 (EDT)
> > "Keith C. Perry" <kperry@daotechnologies.com> wrote:
> >> Two questions...
> >> 1) "higher overhead"
> >> In terms of what specifically.  Memory, cpu, etc...  I can't see a
> >> whitelist cheap being that intensive relative to the full check the
> >> main mail server does.
> > in terms of throughput, if you have to do X  (eg dns lookup)  before
> > doing Y, and what your throughput is. Some mail clusters handles
> > millions of emails, etc. etc
> That is one of the big appeals of postgrey.  You're doing a lookup of
> a host+from combination I believe and checking its timestamp, then you
> either pass on the connection or drop it with a temp failure.  There
> is almost no overhead on the recipient's side.  There is a little more
> overhead on the sender which needs to re-queue the mail, but of course
> the sender doesn't have to deal with spam.
> 
there is a point, depending on your cluster, size and placement - where
postscreen becomes less effective than actual designed greylisting.
so, you need to analyze your environment (now where did I hear that
recently...) 

> >> 2) "...somewhat less effective these days as bots also deal with
> >> delays now."
> >> When you say "deal with",  How so?  Postscreen sounds like it does
> >> for mail what my iptables rule do for my entire net- that is to
> >> say, prevent spammers from over running the server.  I guessing the
> >> Postscreen delay is configurable but are you saying there is some
> >> way around that?
> > the delays - spam as everyone knows, comes from many different
> > sources. The source that postscreen was really good at defending,
> > the botnets was mostly due to the delay happening at the end/last
> > but the bots have become more sophisticated and these days they
> > spawn/wait/come back some of these new bots & controllers are
> > tracked here: http://spamid.net
> I think greylisting must be fairly ubiquitous at this point, which of
> course drives the arms race further.
> However, greylisting will always have one added value: it does impose
> an absolute delay on the delivery of spam.  Even if that delay alone
> doesn't filter any spam like it used to, it does give the blacklists
> time to catch the new threat.  Historically blacklists had trouble
> keeping up with spam bots - if you have a botnet with 100k hosts and
> they each can send 100k emails before the blacklists are updated then
> that is a LOT of mail that gets through.  On the other hand if you
> impose a 15min delay on all of them and a few emails get caught by
> honeypots then the blacklist rules are updated before the botnet
> actually reaches any real hosts, and now all that email gets killed
> before it is accepted.
> I'll have to play around with the new tool when I get a chance.  I
> will say that I've fond greylisting to be very effective.  Most of my
> spam comes in via my gentoo.org address, unfortunately.  I suspect
> most of it is tagged by spamassassin, but very little leaks through my
> gmail spam filters so I tend not to notice it anyway.
> 
blacklists are and have always been reactive and they are not widely
used for drop, but for scoring. You said it in another thread, re: VPS,
clients must be aware of where they spend their dollars. This goes for
email and services as well If people would use spamhaus combi for drop
spam abuse will drop by 50% overnight. But it is not in the best
interests of many to kill spam... ask Bill Gates who famously said that
he would wipe out spam within a year, a decade? ago...





___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug