On Sat, 21 Jan 2017 16:35:12 -0000, David Jones <djo...@ena.com> wrote:
I think the "barrier to entry" is too difficult for most. I would have
to
setup a new MX on a domain without MTA checks (DNS and RBL) then
create a honeypot email address to attract spam if I didn't have
established
recipient addresses/mailboxes.
I may be wrong but I don't believe the majority of the current
masscheckers have honeypots in place. I also believe that at least some
have some form of filtering in place - in fact the most common filtering
in place is the manual classification since I bet most of us come across
the odd message that we second guess and just put to one side.
Then I would have to setup an SA development
environment with scripts to keep it up-to-date from SVN and compiled
regularly.
I forget the exact steps involved for running the checks because basically
I set it up and largely forget about it, but essentially it was grab an
svn copy of SpamAssassin, pick one of the various helper scripts, create a
config and let cron deal with the daily workload of
updating/checking/submitting - it's all done in the helper scripts. You
can write your own if you like too, but in the various options out there
one stands a good chance of meeting your needs.
I only really have to think about it when I move my masschecks to a new
machine.
Finally I would need to manually categorize the ham and spam.
Okay, I agree this part involves doing stuff regularly. The amount will
vary depending on how active you are. Personally? If I am confident a mail
is ham or spam then I am confident that mail could be used for both bayes
training and masschecking. I was going to do that classification anyway so
it's not really any extra for me.
Sure, I could spend more time working to get a few extra samples etc. but
I have found my personal happy balance in terms of input vs output. You're
not expected to neglect your pets to make it perfect. Just, if anyone has
the ability to help out (even a little bit) it might be handy.
What could be just as helpful as actually running masschecks might be
looking at the current documentation and poking at it with a stick. Maybe
it does need tweaking to sound less complicated (I think it's improved
over the years but maybe not enough). It sounds as if there are a couple
of things that could be looked at, perhaps there are more.
