Re: How to use jwhois with Postfix to block spammer

/dev/rob0 wrote:
> Robert Felber wrote:
>
>>> agree, and what I would like to see is greylisting functionality
>>> added to policyd-weight. :) Are you considering doing that? Couldn't
>>> the two be more or less merged into the same service?
>>
>>
>> On my way home yesterday, I thought about that too. But then - I am a
>> unix
>> fan and not a linux fan. And if I am right the unix motto is like:
>>
>> less is more or less more - or
>> many tools for its own purpose and not one big beast.
>
>
> By the same token, you could split the HELO/client rDNS/sender domain
> matching into a daemon separate from the DNSBL checking. But the point
> of a policy service is that it can take multiple factors under
> consideration and deal with them intelligently. (We hope. ;) )
>
> Matching HELO and client and sender is a factor that mitigates the
> result of a positive DNSBL check, and rightly so. But spammers can make
> their domains line up just like anyone else, and some of them do. It
> would be reckless to have policyd-domain-match return an OK before
> calling policyd-rblweight, which would have found this client on SBL-XBL
> and 23 other DNSBL's.
>
> I think greylisting could fit into the calculations as well, as could
> SPF (although it's now my understanding that many spammers do configure
> SPF for their domains, so good SPF shouldn't count too highly.)
> Furthermore, a positive history in other sections of the policy daemon
> could influence deliberations in greylisting.
>
> Postfix itself is split into small tools to do one job well, according
> to the Unix creed. That's why I'm here, and not, say, at Exim. But
> master(8) unites them under a logical umbrella so that Postfix is a
> full-featured MTA.
>
> I agree, bigger is not always better, but I do think that SMTPD access
> policy delegation can be more effective under a single policy daemon. I
> suggest you go home a few more times and reconsider along the way. ;)
> Isn't access policy a single decision, regardless of what factors are
> taken into consideration?
>
> How about a Postfix-like modular structure?
>
> To be candid here, my underlying concerns are with performance and
> simplicity of the Postfix configuration. I closely followed the debates
> here some time back about running Perl daemons, and I'm satisfied that
> it doesn't hurt. But some of my systems are rather weak, notably a
> Celeron 400 and a PII-350 each with 128MB RAM, and I do try to conserve
> resources as much as possible. In addition: the spam problem is
> compounding every day, and resources that are adequate now might not
> remain so in the future.
>
> On the main.cf side I anticipate a structure like this:
> smtpd_recipient_restrictions = [ ... ]
> check_policy_service unix:private/policyd-kitchensink, defer
> So there is only one additional point of failure introduced, and a
> failure in the policy service would not allow spam in. (I see being
> buried in spam as a worse problem than having a few legitimate mails
> delayed.)
>
>> the binutils on unix system have less switches and features as on gnu
>> systems,
>> too.
>>
>> But that is advocacy :)
>
>
> I'm spoiled by GNU, I admit it. :)
>
> Okay, let's look at tar(1). GNU tar gives the user many more features
> than traditional tar implementations. But, the features are logical,
> commonly-needed, and they are implemented in a Unixful way. GNU tar
> doesn't include its own gzip; it calls zlib.
>
> Is GNU tar really that much bigger than other tars? Probably. But it's
> solid and stable, and a heck of a lot more friendly than other tars.
>
> (And consider the humour in that, tar being solid and stable? Isn't it
> usually wet, soft and sticky? And only a hardcore geek could call GNU
> CLI utilities "friendly." :) )
>
> Perhaps I am wrong about all this, but I hope it can spark an
> interesting discussion. Policy services are the future in Postfix
> anti-spam strategies, and I think yours is the most promising of the
> bunch. (No slight nor offense intended to other policy daemons' authors,
> of course.)

The old unix principle has been abused so many times. suffice it to say
that if a program that doesn't help is useless, be it simple or not. so
heading for simplicity, one-task, ... etc isn't the right interpretation
of the unix model. otherwise, unix would be obsolete.