I too am confronting the issues with simscan not knowing the actual destination
user account. I haven't setup SQL bayes (yet -- I hope to soon) but I am using
per-user SQL user prefs.
I have been living with this limitation because blocking spam at the SMTP level
is very important (IMHO) both for simply keeping 90% of incoming mail off the
server, and also for informing senders that their messages were not received
(instead of dropping them into a void).
The solution I've been considering is to run two instances of spamassassin: one
through simscan, with a global bayes db blocking messages scoring about XX (I'm
using 8 actually), and a second instance executed after mail has entered the
system (at the mail-delivery level) that uses per-user bayes and prefs. Yes,
scanning some messages twice. The disadvantages of this I can think of are:
- more server load
- more complex administration
- bayes may not be trained as accurately because most mail will be ham
(?)
The advantages:
+ SMTP-level blocking of most spam
+ per-user bayes and prefs
+ two layers of SA bayes filtering might catch more spam (?)
Maybe the simcan-level SA can run all the non-bayes tests, and use mailfilter
to rewrite the X-Spam-* headers as X-Spam-A-*, while the qmail-level SA can
run nothing BUT the bayes tests and have its headers rewriten as to X-Spam-B-*,
the add the scores together into X-Spam-Status. This would help server load by
splitting the work between the two SAs, and you could see headers for each.
I'm sure a very clever (and simple, as opposed to the above) solution to this
soon. DSPAM support might help!
Specific comments:
> So I found a solution that works. But I'm not sure if there are
> negative implications in doing this (i.e. Performance issues, dropped
> emails, etc).
The load on SA will be the same but I think the load on all the other qmail
processes will increase.
> 2. Created a .qmail file in my account folder
> (/home/vpopmail/domains/somedomain.com/someuser/) that contains the
> following:
Be aware this file will be overwritten or deleted by QmailAdmin when the user
edits any of their forwards/autoresponder settings!
It would be better to place the file at:
/home/vpopmail/domains/somedomain.com/.qmail-someuser
> |/usr/bin/spamc -u [EMAIL PROTECTED] | /var/qmail/bin/preline
> /usr/bin/maildrop -A 'Content-Filter: maildrop-toaster'
> /etc/mail/mailfilter
It sure would be easier if you could just have one global .qmail file. I'm not
sure how to do that, but you could use $(echo $RECIPIENT | sed -r 's/[^-]+-//')
in place of [EMAIL PROTECTED]
> It seems to work great. I just wonder once I put it into production
> with over 100 domains how well it will work. I know I'll have to
> write some scripts to update everyone's .qmail file, but that is fine
> as long as I know it will work under a load.
Let us know how it works!
Quinn
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
