Hey folks,
So, I've been giving this some thought in the last week, as I'm
running into the old "either site bayes or per-user bayes, nothing
in between" issue. I'm using simscan, which passes the first email
address to spamc, so for me it's a per-email-address limitation.
For a majority of my users, that's fine - they only have _one_
email address. For me, it's a problem, as I have dozens of email
addresses that are delivered to me, and sorted via maildrop. Many
of these secondary addresses get tons of spam, but because they're
delivered to aliases, SA never applies bayes scoring, because the
"user" doesn't match the user my bayes database uses (using SQL,
of course).
I would _love_ to have a bayes equivalent of
user_score_sql_custom_query, where spamd would query a table
consisting of something like so:
email_alias CHAR(64)
email_user CHAR(64)
or something similar. That way, I could populate it with data like:
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
etc...
So, in this scenario, an email comes in destined to one of the
many secondary email addresses. spamd makes a query ("SELECT
email_user FROM aliases WHERE email_alias = '$user'"). If spamd
gets a hit, great, try to initialize the bayes database for that
user. If not, skip bayes and go on with life.
Just a thought. It would certainly help me in my situation,
but perhaps I'm just spending a little too much quality time with
the crackpipe.
Good idea? Bad idea? Dumb idea?
Benny
--
"The faster you finish the fight, the less shot you will get."
-- Marine Corps Rules for
Gunfighting
