Just a follow up / FYI...
The following doesn't work in a few cases:
$(echo $RECIPIENT | sed -r 's/[^-]+-//') in place of [EMAIL PROTECTED] in your
.qmail file
And the cases are:
1. If the domain actually has a dash in it (ie. some-domain.com) (note:
as a hack I repeated the sed command which works for domains with a
single dash but not domains with more than one dash)
2. If the domain has domain aliases (it will use whatever domain is in
the recipient)
So I basically updated all my domains with the line above in everyone's
.qmail file and then just went back and manually typed the account name
for domains that fall into the two categories above.
So now I'm basically monitoring the server to see how it performs
without using simscan for spam scanning and instead using the .qmail
files to process scanning for spam. Seems ok as far as I can see. I
guess time will tell.
Quinn Comendant wrote:
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]
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
