From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PhB9x-0003Gm-68 for garchives@archives.gentoo.org; Mon, 24 Jan 2011 01:23:57 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4824FE08EE; Mon, 24 Jan 2011 01:22:12 +0000 (UTC) Received: from www01.badapple.net (www01.badapple.net [64.79.219.163]) by pigeon.gentoo.org (Postfix) with ESMTP id 19927E08EE for ; Mon, 24 Jan 2011 01:22:11 +0000 (UTC) Received: from [127.0.0.1] (unknown [76.14.68.122]) (Authenticated sender: ramin@badapple.net) by www01.badapple.net (Postfix) with ESMTPSA id B80B6844E079 for ; Sun, 23 Jan 2011 17:22:10 -0800 (PST) Message-ID: <4D3CD441.6010206@badapple.net> Date: Sun, 23 Jan 2011 17:22:09 -0800 From: kashani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Setting up SMTP relay References: <4D3B4D53.7000209@wonkology.org> <201101232220.43766.alan.mckinnon@gmail.com> <4D3CC19A.9080100@badapple.net> <201101240226.24738.alan.mckinnon@gmail.com> In-Reply-To: <201101240226.24738.alan.mckinnon@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: X-Archives-Hash: 9b70e17a3e57d0c119766493af7a0060 On 1/23/2011 4:26 PM, Alan McKinnon wrote: > Apparently, though unproven, at 02:02 on Monday 24 January 2011, kashani did > opine thusly: > >> On 1/23/2011 12:20 PM, Alan McKinnon wrote: >>> It manages it's own queues beautifully. But, and this makes me sad, it >>> doesn't really want *me* to manage it's queues. Border controls are >>> hard, and finding the 1,000 mails some idiot with a Windows bot just >>> sent, and deleting them, is really hard. >>> >>> I'm redesigning our mail setup at work,a nd I'm going to do it with exim >>> *and* Postfix. Exim is the front end I can see, work with, and manage. >>> Exim sends on to Postfix as fast as it can, and Postfix transparently >>> relays to recipient. I get best of both worlds :-) >> >> I can't say I've ever needed anything more than mailq | grep |awk | >> postsuper -d - in order to delete mail from the Postfix queues. What >> sort of things are your trying to do other than delete a lot of spam or >> bounces? > > First, our internal mail system deals with about 3,000,000 mails a day Mon-Thu > so grep | postsuper is a tad inadequate, even if just on the basis of volume > > The basic tools are fine as long as you understand what they are dealing with > - raw text. As soon as you run mailq you have text, you no longer have > intelligence about what that text means. So you need lots of grep-fu. > > I can't control what the users mail out, sometimes they have automated systems > that do silly things like send 10,000 notifications an hour to an SMS gateway > when they cocked up Nagios. Finding the dodgy ones is no fun when there's a > lot of perfectly valid ones in the mix too, and grep doesn't help much other > than blindly selecting text matches. > > There's lots more examples, but they all follow a similar theme. > Thanks for the extra detail, I found what you're describing very interesting. I've never dealt with Postfix with more than a couple hundred internal users and more often as spam our customers system. Other than the occasional Nagios blasts I haven't had to deal with much of this. In regards to controlling what users send is it feasible to use a policy server for rate limiting them? The ability to use an extra lookup service to decide whether to access main, filter it, allow relay, etc is one of the things I think Postfix does well. However I suspect the management and hand holding of a rate limit system would create more overhead than cleaning out the queue periodically. kashani