I had not approached it that way because I was looking for something which would allow me to centralize the configuration in sendmail. I am trying to avoid configuring any user specific information into spamasassin at this point.

I figured that being able to decide not to launch any spamassassin activity would be cleaner.

The cost here is the spawning of the external filter (which can do anything, so thats pretty flexible).

The example script I showed potentialy launches 1 editmap query for the full email address, an additional editmap query for each part of the domain name (e.g. my.local.host.com, local.host.com, host.com, com), 1 editmap query for the localpart (user@) and one more editmap query for the Spam: tag alone (can be used to provide default behavior).

This is an average of 5 editmap queries against the sendmail access.db. According to my (this is a modest sub Ghz dual proc with 25000-30000+ connections daily) syslog debug entries, this all happens in under a second.

On this system, a normal processing of a message is almost never less than 2 seconds, average of 3-4.

The new version of the patch is still running happily since I installed it yesterday on my system.

I have an untested version of the patch against CVS.

IF all recipients are filtered, the milter will cease processing of the email.

Patch is rough and uses the system(3) call.
Uses debug flag D_RCPT

patches are against 0.2.0
supplied is patch for debian package

Also supplied is a shell script to illustrate filtering out recipients who are Spam: friend in sendmail access.

Joe