Покотиленко Костик put forth on 10/27/2010 7:20 AM:
> Can somebody comment on this please.
>
> В Вто, 26/10/2010 в 18:20 +0300, Покотиленко Костик пишет:
>> I'm now trying to move all RBL and RHSBL checks to policyd-weight. In
>> policyd-weight I set "$ADD_X_HEADER = 1" and very high score so it never
>> match.
>>
>> Then I plan to parse "X-policyd-weight" header with sieve script on
>> cyrus to move spam to separate imap folder. Header looks like this:
Why do you want to accept spam and save it somewhere instead of
rejecting the SMTP connection? If you're doing anti-spam correctly, the
few that make it through are easily dealt with in the inbox. Setting up
"spam" or "junk" folders is adding unneeded complexity. Most users
never check their "spam" folders, if they exist.
>>> which is working fine but...
>>>
>>> sorbs.net is very agressive, many ISPs get blocked for several years and
>>> are not willing to delist b/c sorbs doesn't offer free delist for them.
>>>
>>> So there is problem with false-positives. There are not much of them,
>>> but all cases needs additional investigation.
This is exactly why many OPs no longer use SORBS, myself included.
Their listing and delisting policies don't fit well with the modern
world. Listing MTA IPs at Gorilla mailers (Gmail, Yahoo, Hotmail, etc)
due to a small spam run hitting SORBS traps is a stupid idea. This is
absolutely the worst possible way to try to deal with spam coming from
such operations. The listing are always too late to stop the spam run
from reaching SORBS clients, so all this does is end up blocking tons of
ham.
>>> >From other side this combination (spamhaus.org + sorbs.net) doesn't pass
>>> spam almost at all, they even doesn't leave anything for spamassassin,
>>> so I don't want to remove checks.
That may be, but look at the damage SORBS is doing. You're expending
all of this effort to minimize "false positives" generated by SORBS.
Instead of jumping through all these hoops to minimize the damage SORBS
is doing to your operation, simply stop using SORBS' lists and use other
measures to pick up the slack. Barracuda's BRBL is probably just as
effective, and without the large number of FPs.
>>> 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.
Try this out for a week or two:
1. Comment out your SORBS entries in main.cf
2. Implement reject_rbl_client b.barracudacentral.org
See http://www.barracudacentral.org/rbl as sign up is required
3. Implement this dynamic/generic (residential/zombie) blocking PCRE
check_client_access pcre:/etc/postfix/fqrdns.pcre
http://www.hardwarefreak.com/fqrdns.pcre
Put the PCRE check before all of your RBL checks. Local table lookups
are infinitely faster than DNS queries, so if the PCRE table can block a
client spam MTA, it's much faster to do so than perform a DNS lookup to
accomplish the same task. Post feedback here as to how well this works
for you. Others here have had tremendous success merely by adding this
PCRE alone. It's not magic but it kills a lot of spam connections from
zombies, including many IP not listed on any "dialup/dynamic" lists such
as the PBL and SORBS dyn list.
--
Stan
