>> Hence why I have spamassassin used to filter after the mail is queued. >> Do you make mimedefang run spamassassin on all your mails before queueing? >> > > Inbound only, and after the other faster checks (virus, etc.) that > might cause rejection are done. The advantage of scanning during > the SMTP conversation is that you can still reject with a > message that would find its way back to a legitimate sender > without having to construct the bounce yourself. > I don't bounce the mail. I just tag the mail as a possible spam. Different ways of handling this :) > >> Okay, I get it. lotsa sendmail processes < (one socket per sendmail >> process) > single milter process < ? > perl processes >> > > Actually you can have multiple milter processes if you want, but > MimeDefang handles about everything. Also, sendmail has separate > conversations with the milter(s) for each operation which > MimeDefang might hand off to different slaves. The side effect > is that you don't block on some other long-running process unless > you are out of slaves but you also can't count on globals that > you set in one step (checking the sender or recipients) to be > available in later steps - but MimeDefang passes most of the > information you need each time and has dropped a complete > copy of the message broken out into its MIME components in > files where the programs can find them (hence the name and > the advantage of running multiple scanners under its control). > > So you are saying that mimedefang is not reliable if not provided enough resources. What happens to the mail then? temporary reject or let through?