1 |
Apparently, though unproven, at 09:00 on Monday 24 January 2011, Mick did |
2 |
opine thusly: |
3 |
|
4 |
> On Monday 24 January 2011 01:22:09 kashani wrote: |
5 |
> > On 1/23/2011 4:26 PM, Alan McKinnon wrote: |
6 |
> > > Apparently, though unproven, at 02:02 on Monday 24 January 2011, |
7 |
> > > kashani did |
8 |
> > > |
9 |
> > > opine thusly: |
10 |
> > >> On 1/23/2011 12:20 PM, Alan McKinnon wrote: |
11 |
> > >>> It manages it's own queues beautifully. But, and this makes me sad, |
12 |
> > >>> it doesn't really want *me* to manage it's queues. Border controls |
13 |
> > >>> are hard, and finding the 1,000 mails some idiot with a Windows bot |
14 |
> > >>> just sent, and deleting them, is really hard. |
15 |
> > >>> |
16 |
> > >>> I'm redesigning our mail setup at work,a nd I'm going to do it with |
17 |
> > >>> exim *and* Postfix. Exim is the front end I can see, work with, and |
18 |
> > >>> manage. Exim sends on to Postfix as fast as it can, and Postfix |
19 |
> > >>> transparently relays to recipient. I get best of both worlds :-) |
20 |
> > >>> |
21 |
> > >> I can't say I've ever needed anything more than mailq | grep |awk | |
22 |
> > >> |
23 |
> > >> postsuper -d - in order to delete mail from the Postfix queues. What |
24 |
> > >> sort of things are your trying to do other than delete a lot of spam |
25 |
> > >> or bounces? |
26 |
> > > |
27 |
> > > First, our internal mail system deals with about 3,000,000 mails a day |
28 |
> > > Mon-Thu so grep | postsuper is a tad inadequate, even if just on the |
29 |
> > > basis of volume |
30 |
> > > |
31 |
> > > The basic tools are fine as long as you understand what they are |
32 |
> > > dealing with - raw text. As soon as you run mailq you have text, you |
33 |
> > > no longer have intelligence about what that text means. So you need |
34 |
> > > lots of grep-fu. |
35 |
> > > |
36 |
> > > I can't control what the users mail out, sometimes they have automated |
37 |
> > > systems that do silly things like send 10,000 notifications an hour to |
38 |
> > > an SMS gateway when they cocked up Nagios. Finding the dodgy ones is no |
39 |
> > > fun when there's a lot of perfectly valid ones in the mix too, and grep |
40 |
> > > doesn't help much other than blindly selecting text matches. |
41 |
> > > |
42 |
> > > There's lots more examples, but they all follow a similar theme. |
43 |
> > |
44 |
> > Thanks for the extra detail, I found what you're describing very |
45 |
> > |
46 |
> > interesting. I've never dealt with Postfix with more than a couple |
47 |
> > hundred internal users and more often as spam our customers system. |
48 |
> > Other than the occasional Nagios blasts I haven't had to deal with much |
49 |
> > of this. |
50 |
> > |
51 |
> > In regards to controlling what users send is it feasible to use a |
52 |
> > |
53 |
> > policy server for rate limiting them? The ability to use an extra lookup |
54 |
> > service to decide whether to access main, filter it, allow relay, etc is |
55 |
> > one of the things I think Postfix does well. However I suspect the |
56 |
> > management and hand holding of a rate limit system would create more |
57 |
> > overhead than cleaning out the queue periodically. |
58 |
> |
59 |
> [Off-topic] Can't you set up nagios to only send out a single alert when a |
60 |
> monitored variable goes down - can't remember the parameter off hand but |
61 |
> that's what I did when the default nagios setting proved to be too trigger |
62 |
> happy for the users' needs. |
63 |
|
64 |
I could do that for my Nagios instance, but don't want to. My Nagios instance |
65 |
is well-behaved, there are others which are not so much. |
66 |
|
67 |
-- |
68 |
alan dot mckinnon at gmail dot com |