mouss, > Henrik K a écrit : > > Using amavisd-milter is much better option, you can control concurrent > > process amount and socket queue. > > how? > > if you configure postfix to accept 100 simultaneous connections, then > you should be prepared to filter 100 simultaneous messages (I am talking > pre-queue here). > > but even assuming a single message. if the time it takes to scan is > long, the client may disconnect. I don't know if caching would help here > (so that next time, the message is filtered quickly).
Using a milter setup (through Petr Rehor's amavisd-milter) is slightly better regarding the use of resources and client handling, compared to smtp-proxy. The difference is in client's SMTP session handling up to the DATA stage. With a proxy approach amavisd is tied up from the very beginning of the SMTP session, up to and including a data transfer from the client. With a milter approach, Postfix and amavisd-milter handle a client's session by themselves up to the final dot at the end of a data transfer. Only at this point is amavisd contacted. Moreover, the socket connection request from amavisd-milter goes into a socket's connection queue (handled by kernel) and need not be accepted by amavisd right away. Both facts together make it possible to have somewhat less running child processes compared to the proxy setup. If slow client sessions are common, this difference may be important. Unfortunately the milter approach is more restricted in its functionality than proxy or post-queue setups, because header edits can't be applied per-recipient in multi-recipient mail. Ralf, > amavis[27477]: (27477-10) (!)ESMTP: NOTICE: Connection broken during > data transfer > amavis[27477]: (27477-20) load: 7 %, total idle 7483.147 s, busy 541.002 > s amavis needs too long time, to check the mail. See busy 541.002 s. This measures total busy time of this process (in all 20 sessions up to this one in your case). The TIMING log entry (at log level 2) is what is relevant for each mail transaction. > Postfix timeout is > smtpd_proxy_timeout = 300 The smtpd_proxy_timeout should be above $child_timeout (with some margin). The relevant settings on the amavisd side are: # timeout for our processing: $child_timeout = 8*60; # abort child if it does not complete a task in n sec # timeout for waiting on client input: $smtpd_timeout = 8*60; # disconnect session if client is idle for too long; # $smtpd_timeout should be higher than Postfix's max_idle (default 100s) If you can afford wasting extra memory, amavisd allows you to run SpamAssassin as a forked process: $sa_spawned = 1; At the expense of up-to-double the number of amavisd processes and correspondingly increased virtual memory footprint, a benefit is that long SpamAssassin processing can be cleanly aborted by a parent amavisd process when elapsed time approaches a deadline. It may be worth experimenting with this. Mark ------------------------------------------------------------------------------ _______________________________________________ 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/
