> For starters, how do I set all connections test to scoring only? Is that
> the PB setting (Penalize Bad Ip's: 3 - score only)?
Yes, it adds to the PB score and adds the ASSP spam reason header.
> I assume I leave the log settings to the defaults in this case (ie: store
> blacklisted domains: 3, spam helos: 3, etc..)
Yes at first. Change these only if you start to see adverse conditions
caused by them.
> By following your procedure, I would be centrally collecting all messages
> that fail Spam tests other than Bayesian - correct? ie: RBL tests,
> SpamBomb tests, PB tests, etc... So for all valid email that fails those
> tests, the sender won't be notified that it wasn't accepted, and the user
> won't have received it because it would be in a central area. Is that
> correct?
I don't think the sender will receive any notice if you accept the email
even though it is marked as spam. ASSP only notifies by rejecting with a
response code so if you don't reject it they get no notice, I think.
> What do I do with legit emails at this point? Just delete them? The user
> won't have received their email though....
That's up to you and how bad you want to hide the fact that you are managing
their email so they don't get up in arms about privacy. You could delete
the email, set ASSP to accept the next one, and respond to the sender from
an official looking email address like admin@ or emailsupport@ and report
that due to an error their email needs to be resent, or you could silmply
forward it to the recipient as an attachment from said official address.
Depending on your MTA you could also simply move the email to the
recipient's email folder to be retrieved by them.
> And what becomes the point of centrally collecting them using the MTA's
> rule?
The connection based tests have very few false pos, but just in case you
will have the email. The CC all spam does the same thing but will include
Bayesian, which is what I use. The only reason to redirect them using the
MTA rule is to keep them from getting to the users but not deleteing them.
If your MTA supports a spam folder then you could direct those to the
individual's spam folder, which is what I do.
>> BTW, delaying makes a huge difference right off the bat. It also will
>> almost completely eliminate the virus laden emails, almost.
>
> Oh - I am certain of that, which is why I'm extremely eager to get this up
> and running, but don't want to make a mistake while building the db, and
> get lynched for dropping valid emails.
If lynching is a huge worry, then I say don't redirect or block any email to
begin with. Go ahead and let ASSP mark spam with [SPAM] and just pass it
along. Those users who are inundated with spam can be worked with and you
will have the CC'd spam to analyze.
The easiest way I have found to do error checking is to place the CC'd spam
in different folders depending on what test failed. So I have Bayesian,
RBL, SPF, PBLV1, HELOformat, etc. folders in my address that receives all
our spam. I can then simply click on the folder for RBL failures and see if
anything looks legitimate. If it does I can take action to prevent future
problems. And yes, I have spent a bit of time doing this but the payoff is
in almost 0% false positives on the emails that are sent to the spambox and
a very high confidence in the Bayesian spams. BTW, Bayesian spams that have
a spam probability of 1 and a confidence of 0.9999 go to the user's spambox
too by way of an MTA rule.
Doug Traylor
|