For now almost a week without sorbs and wothout spam. Remebered that the metter I was installed sorbs list was many forged freemail spams. That time I've done client/hello/sender match check for a list of free mail services (discussed on this list). And I was also advised to add sorbs, b/c all cases with forged freemails were listed there.
So, now sorbs removed, client/hello/sender match check is working, and no spam. В Чтв, 28/10/2010 в 22:07 -0500, Stan Hoeppner пишет: > Покотиленко Костик 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 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? > > 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 main.cf so it gets first crack at the > connections. You will likely be pleasantly surprised by the results. > -- Покотиленко Костик <cas...@meteor.dp.ua>
