So I have a crazy idea, and want someone (*cough* Gordon *cough* Sam) to tear them to shreds.

I'd like to run spamc inside a courier filter, and if the score is too high, reject the message at the smtp layer. (That's not crazy.) The "problem" with this is that some users invariably do not want their messages filtered, while others do -- or more precisely, different users have different thresholds for message rejection. Since it's only possible to reject or accept the message for all recipients, such a filter seems unattainable.

What issues are there with writing a filter that looks at *all* of the recipients, finds the *highest* threshold (lower being more restrictive), and uses that? (Extend to include blacklists and whitelists...)

Example: 1. alice@example has "reject" threshold at 7; bob@example has "reject" threshold at 9. 2. messages comes with rcpt to: both alice and bob. 3. filter looks up both alice and bob's prefs; determines the least restrictive settings as "threshold=9", and if whitelisting/blacklisting is available, looks for the appropriate union of those settings too. 4. invoke spamc, reject if >=9; accept otherwise.

Obviously this means that some preferences aren't always honored - but it does mean that no one's email will ever be filtered below their threshold. I expect that 99% of spam messages coming in won't even meet this condition; but it's this condition that's prevented us from placing spamassassin in at the front door to *reject* messages. (Does Barracuda do something like this? Or are they just always accepting mail?)

The problems I could see with this surround just aliases and dash-extensions. Those should just be implementation annoyances: I'd have aliases have their own spam settings in our database; and manually look for the non dash-extension address for the later.

Any other problems?

Thanks!!

best, Jeff