Wow. Thank you all for the good discussion, which has led me to a different way of thinking how to handle this.

I can see why there isn't a concensus on how to handle per-user configurations, namely because there doesn't seem to be a Right Way to do it (yet). The architecture of SMTP doesn't help the situation, either.

The only blocks I can see working per-user are plugins that run at RCPT time, such as those that check HELO, the MAIL FROM address, reverse DNS, and dnsbl/rhsbl. The comparisons in those plugins' hook-rcpt subs would have to compare against either the user's config or the general one. But in the end, I'm guessing you would block a la "5xx User does not exist (i.e. you're spammy scum and this user doesn't want your mail)".

Of course the content filters (anti-virus, spamassassin, subject checkers) would have to wait until later. If I did what Skaag did with user Junk folders, I'm closer to my intended goal. Each user could still pick and choose certain 'front-end' filters to run (from/to pairs, helo, maybe dnsbl's) and then pick some basic spamassassin rulesets for the 'back end'.

Once it passes all the qpsmtpd checks and is queued, it runs through maildrop, which runs spamassassin on their rulesets (and each user gets their own Bayesian database this way.. much more effective, no?) then delivers to /Maildir/new or /Maildir/Junk/new. Downside here is having to run SA a lot.

The logging plugin would then save off any 5xx denials made in their behalf and an email report could be sent to them every day or so telling them who was blocked (for those who care to know).

Any problems with this train of thought?

-- Bryan

Reply via email to