| 1 |
On 12/03/2011 09:48 PM, Pandu Poluan wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> Thanks! Very helpful resources. |
| 5 |
> |
| 6 |
> You mentioned amavisd-new. What's their relationship? I mean, if I |
| 7 |
> deploy postscreen, how will it affect amavisd-new? |
| 8 |
> |
| 9 |
|
| 10 |
Postscreen sits in front of smtpd, and handles all incoming connections. |
| 11 |
It hands the "good" connections off to the real smtpd daemon. |
| 12 |
Amavisd-new (in both before/after-queue configurations) interacts with |
| 13 |
the real smtpd, so postscreen doesn't directly affect it at all. |
| 14 |
|
| 15 |
What was I talking about? |
| 16 |
|
| 17 |
With amavisd-new, a before-queue filter is generally nicer, because you |
| 18 |
can reject spam, notifying the sender, rather than discarding it or |
| 19 |
backscattering. But, amavisd-new is a hog, and with a before-queue |
| 20 |
filter, an amavis process gets used every time ANY connection is made. |
| 21 |
Since 95% of your connections will be crap (that is a technical term), |
| 22 |
you waste tons of resources creating/killing amavisd-new processes for |
| 23 |
botnets and other scum that will be rejected quickly. |
| 24 |
|
| 25 |
On a busy server, it will kill you. |
| 26 |
|
| 27 |
Postscreen only passes the "good" connections to a real smtpd, so with |
| 28 |
postscreen running, new amavis processes only get used for those good |
| 29 |
connections. If postscreen can get reject 90% of the incoming |
| 30 |
connections, you'll use an order of magnitude less resources doing |
| 31 |
before-queue filtering than you would without postscreen. |
| 32 |
|
| 33 |
So, in essence, postscreen is what allows you to run the before-queue |
| 34 |
filter with comparable resources to the after-queue filter. |
Archives