Using MIMEDefang.
A big con is that we can't send back different reply codes to the bad guy.
The multiplexor is to avoid multi-threaded perl - they think it's evil. It also allows the milter to talk directly to the child processes without going through the multiplexor.
We can implement this in MTAs other than sendmail at the mimedefang process.
Not convinced there's any performance gain in having the filter on a different machine...
There's a difference between CONTINUE and ACCEPT.
defang and the multiplexor must run on a single machine - they share files.
sendmail itself still runs its own checks - but still calls defang stuff without saying it's going to fail anyway.
We can't distinguish between a HELO and an EHLO.
There's some sanity checking - if you issue conflicting codes and errors, it will change the code for you.
David does not recommend trying to implement tarpits or firewalls.
Later versions of defang have an interlock with a virus scanner - it disables action_notify_sender if a virus is detected, for instance.
SURBL lists URLs that are used to sell spam (within the message body).
If the ultimate SMTP recipient server is down, it generates a tempfail. Also you can increase the load on end machine, and it doesn't cache results (but you can write this yourself).
sendmail 8.13 has throttling - use that instead because it's much more efficient.
(p126)
Issues to consider when using streaming:
Tradeoffs with stacking MD and SA milters:
Look at Spamassassin 3. Might use tick requests to queue up salearn stuff.
p138 - you can implement SPF with it. Ugly though. He uses it for hotmail and yahoo.
Recommends against using RBLs to reject. spamhaus is good. He recommends also using Perl 5.8 to implement this, says it's better than < .8.
Ideally, you use defang on each secondary MX host.
Uses clamav as well - David likes it. Go for the daemon version.
-- MikePatterson - 26 Apr 2005