Re: How to use jwhois with Postfix to block spammer

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.)
--
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header