I removed dsbl just now. I have not been able to locate the message in the log that triggered it yet. I will keep looking, got side tracked by a support call.
On Tue, Jan 13, 2009 at 10:56 AM, Noel Jones <njo...@megan.vbhcs.org> wrote: > Guy Story KC5GOI wrote: > >> I received the following error for the first time yesterday in my logwatch >> report. It was in the Postfix section. >> >> 1 *Warning: Pre-queue content-filter connection overload >> ---------------------------------- >> 1 After CONNECT >> 1 unknown unknown >> > > You'll need to find the postfix log message that triggers this. > > Likely it's unrelated to "pre-queue content-filter connection overload" > > Maybe your postfix-logwatch module needs updating. 7.3.6 is the version I installed via apt two weeks ago. It is the first time I saw this so it has me a bit curious. > > > >> >> I have read over the page on before queue content filter. If I understand >> it correctly my specific access controls, rbls and such are part of the >> pre-queue process. It that correct? Could the warning be due to a >> excessive amount of time talking to an rbl or to many connections at one >> point in time? If it is too many connections from a single source, the >> paranoid side of my mind says DOS attack or abnormal volume of spam. Given >> that it is showing as unknown (logwatch did not show the ip and I am not >> finding the error in mail.log or mail.warn), I do not even know who to block >> at the firewall. >> > > Without more detail, no one has any idea if it's a real problem or not... Once I find it I will let you know. Grepping the log files for that verbiage has not be fruitful yet. > > > >> Below is copy of the smtpd_recipient_restrictions if someone asks. >> >> smtpd_recipient_restrictions = permit_sasl_authenticated, >> permit_mynetworks, reject_unauth_destination, >> check_client_access cidr:/etc/postfix/client.cidr >> check_client_access hash:/etc/postfix/blacklist >> check_helo_access hash:/etc/postfix/helo_checks, >> reject_rbl_client ru.countries.nerd.dk < >> http://ru.countries.nerd.dk>, >> reject_rbl_client tm.countries.nerd.dk < >> http://tm.countries.nerd.dk>, >> reject_rbl_client cn.countries.nerd.dk < >> http://cn.countries.nerd.dk>, >> reject_rbl_client zen.spamhaus.org <http://zen.spamhaus.org>, >> reject_rbl_client bl.spamcop.net <http://bl.spamcop.net>, >> reject_rbl_client list.dsbl.org <http://list.dsbl.org>, >> reject_rbl_client korea.services.net <http://korea.services.net>, >> reject_rbl_client bhnc.njabl.org <http://bhnc.njabl.org>, >> reject_rbl_client combined.njabl.org <http://combined.njabl.org>, >> check_policy_service inet:127.0.0.1:60000 < >> http://127.0.0.1:60000> >> > > > list.dsbl.org is empty/dead and should be removed, but it won't cause > errors (yet). > Make sure you're not getting timeout messages in your logs from any other > RBL lookups, otherwise it's OK. Done, one less delay on processing. > > > >> >> I did notice a higher than normal amount of mail for my server yesterday >> including a much higher than normal attempt to relay through us. I am >> trying to use rbls with Postfix before my other spam filtering since I can >> decline the connect instead of Postfix digesting it and passing it on. It >> should decrease the overall system load if I do not have to receive the >> email content. >> >> The overall question is: Is this too much filtering or a possible DOS >> attack? This has never happened before so I do not suspect hardware >> problems, just too much of something talking to us. >> > > Without details we're just guessing. My guess is this isn't a real > problem. > > 73, > > -- > Noel Jones > It has only happened once in the course of a year so it may be a one time deal. I am mainly curious at this point. I will keep digging for the error. If logwatch found it, I can. I agree that it may not be a real problem. Mail has not stopped being processed. No one is complaining. -- 73 Guy Story KC5GOI kc5...@gmail.com
