postfix-users October 2010 archive
Main Archive Page > Month Archives  > postfix-users archives
postfix-users: Re: Posfix: deliver to spam folder analog of reje

Re: Posfix: deliver to spam folder analog of reject_rbl_client

From: Stan Hoeppner <stan_at_nospam>
Date: Fri Oct 29 2010 - 03:07:17 GMT

Покотиленко Костик put forth on 10/28/2010 5:31 AM:

> a. mail was send directly from company's public ip which is DSL (shouldn't send direct)
> b. advertising company's mail server doesn't have revers DNS
> c. doesn't send proper hello
> d. advertising company's ip black listed by sorbs

Ahh, I see. You live in one of "those" internet neighborhoods.

> Whitelists are growing fast in my experience, so I'm looking for solutions which work
> well and doesn't need much attention from my side. Most should work automatic, rest is
> left to user's attention. I should only support this ballance.

And whitelists that never stop growing are often the most popular
solution, as you've done. Have you tried a content filter such as
SpamAssassin, turning off the client dnsbl function and relying on Bayes
and rhsbl checks of header/body domains? SA's built in tagging function
would allow you to easily filter to user spam folder with sieve,
procmail, or maildrop. This setup might help you eliminate the FPs or
drop them into the spam folder instead of rejecting them.

> This worth experementing. In my experience sorbs blocks much more spam (not
> blocked by the rest) than producing FP. That's why I'm looking for solution
> to make those FPs easy recoverable.

Until hearing from you, I'd never heard an OP state that SORBS was so
effective at catching spam the other dnsbls did not that they were
willing to accept and deal with the FP rate of SORBS. Maybe this is due
to your location in eastern Europe?

> Several months statistic on my own mailbox shows that without sorbs I was
> getting 3-10 spams a day. With sorbs I recover 1-5 messages a week for
> entire ~200 users. Well, this is not counting 41 blocked messages from
> this list this week.

This is good example of why SORBS sucks and why the FPs are not
acceptable. They list the postfix-users outbound list server IP
(probably shared with other lists) due to a trap hit(s), even though the
ham ratio is 100% on most days. I'm sure there was no "spam run" but
merely a couple of hits. Again, bad policy, and why I haven't used
SORBS for years.

Usually when I sign up for a mailing list I manually add a whitelist
entry, or I just let my auto whitelisting script take care of it.

> This worth trying, thanks.

I'm not saying BRBL is a great dnsbl, but from what I hear from other
OPs it's pretty decent and as good or better than SORBS without the high
FPs. I tried it out for a while but it wasn't catching much so I dumped
it. Most dnsbls don't catch much spam here because my other A/S
countermeasures kill most of it first. dnsbls get crumbs here, same
with postgrey.

>>>>> So the question is: how it is possible to direct SPAM mail to a user's
>>>>> imap spam folder?
>> The answer is don't do this. Reject the spam during the SMTP connection.
> This is costy in management.

If you have filters with higher accuracy that don't cause FPs it's not
costly in management.

>> Try this out for a week or two:
>> 1. Comment out your SORBS entries in
>> 2. Implement reject_rbl_client
>> See as sign up is required
>> 3. Implement this dynamic/generic (residential/zombie) blocking PCRE
>> check_client_access pcre:/etc/postfix/fqrdns.pcre
> Who's supporting this file?

There is no support, and none needed. It's a home grown regular
expression table that matches fully qualified reverse or forward DNS
names of connecting clients. It targets dynamic IPs and generic static
IPs of broadband providers around the world, mostly in the US and
Europe, but includes some others around the world. I.e. it blocks
direct senders who shouldn't be sending direct. It's much like the
Spamhaus PBL regarding results, but blocks many client IPs that the PBL,
SORBS DUL, and other "dynamic" dnsbls don't.

If you don't trust it because no big vendor name is behind it, use sed
and replace REJECT with "WARN fqrdns". Monitor its effectiveness by
greping your log for "fqrdns".

Put it above your RBL checks in so it gets first crack at the
connections. You will likely be pleasantly surprised by the results.

-- Stan