> Покотиленко Костик 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.
Well, the idea is to reject by DNSBLs which are proven to not produce FPs, and in addition just mark SPAM by agressive DNSBLs, then move marked to SPAM folder. We are supporting IT for several corporations in Ukraine. Here it's hard to many to do things right. Wierd example: PR manager can't get mail from advertising company - it turns that mail was not accepted b/c: 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 ... You say to PR manager, it's their fault, their mail system doesn't set up properly. PR manager tells you that everybody except us in this city can get mail from them. And this is true. Here I have 2 options: either I add whitelist or PR manager moves to mail.ru/yahoo.com/gmail.com... Also, some "smart" users getting the rules of this game fast, they tell - I've sent a message and waiting for replay, please add this address to a whitelist :) 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. > >>> 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. 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. 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. > >>> >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. This worth trying, thanks. > >>> 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. > 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 Who's supporting this file? > 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
