| 1 |
Apparently, though unproven, at 03:22 on Monday 24 January 2011, kashani did |
| 2 |
opine thusly: |
| 3 |
|
| 4 |
> > There's lots more examples, but they all follow a similar theme. |
| 5 |
> |
| 6 |
> Thanks for the extra detail, I found what you're describing very |
| 7 |
> interesting. I've never dealt with Postfix with more than a couple |
| 8 |
> hundred internal users and more often as spam our customers system. |
| 9 |
> Other than the occasional Nagios blasts I haven't had to deal with much |
| 10 |
> of this. |
| 11 |
> In regards to controlling what users send is it feasible to use a |
| 12 |
> policy server for rate limiting them? The ability to use an extra lookup |
| 13 |
> service to decide whether to access main, filter it, allow relay, etc is |
| 14 |
> one of the things I think Postfix does well. However I suspect the |
| 15 |
> management and hand holding of a rate limit system would create more |
| 16 |
> overhead than cleaning out the queue periodically. |
| 17 |
|
| 18 |
Your last sentence is the right one. |
| 19 |
|
| 20 |
Dealing with issues arising only when they arise is infinitely easier than |
| 21 |
trying to maintain some arb list of $STUFF just in case a minority of users |
| 22 |
misconfigure their boxes. |
| 23 |
|
| 24 |
On the whole, our users send only valid mail and all of it must be allowed to |
| 25 |
pass. |
| 26 |
|
| 27 |
The problems come in when a automated system mail goes beserk, usually causing |
| 28 |
loops. Not spam though, there's a rather large Cisco Ironport in front of my |
| 29 |
MTAs which deals with that. |
| 30 |
|
| 31 |
-- |
| 32 |
alan dot mckinnon at gmail dot com |
Archives