Sahil Tandon wrote:
* Oskar Liljeblad [EMAIL PROTECTED] [05-16-2008]:
if you are running amavisd-new after the queue, then it is too late to
reject spam: this will only cause backscatter.
That's why I only use amavis before queue! IMHO after-queue is not
acceptable nowadays unless you have very big mail volumes and very
poor hardware...
FUD. You can use amavisd-new after-queue and just configure it not to send
backscatter. That is entirely acceptable.
and after the queue has some benefits (whether they are important or not
is not debated here).
[I am not saying that either mode is the Right Thing. Just that
after-the-queue is more than acceptable nowadays:-]
- you decide when to scan. in a pre-queue, it is the attacker who decides.
- less delay for legitimate mail. In a setup (like mine, as I am not a
quarantine-fan;-p) where most spam is rejected by postfix restrictions,
amavisd-new gets mostly ham, so pre-queue would harm more legitimate
senders than spammers...
- also, there is no risk to cause a client timeout. so one can do any
checks he wants (with a pre-queue, one cannot run checks that take a
long time. and this is not only hardware specific. when you query remote
services, your hardware is only part of the equation)
- still in the same spirit, it is possible to delay checking of certain
messages and to (re)check them later. I'll give two examples:
*) some spam reaches both a valid recipient and a spam trap. by
delaying the check for valid recipients, there are some chances that the
same (or similar) spam hits the trap.
*) it may take time for DNSBLs and URIBLs to list an ip/host/uri.
- with a pre-queue, you need as many listeners as your smtpd listeners.
with an after the queue setup, you don't need to run that many
listeners. Admittedly, this may not be an issue if you have enough
resources, but some may consider this a waste of these resources.
The standard argument for pre-queue is to reject the messages caught by
your filter so as to leave FP handling to the sender. but this is
debatable.
To sum this up, one size doesn't fit all sites...
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
AMaViS-user mailing list
AMaViS-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
