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/vse0120000070mrt/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/
