On 09/05/13 17:38, Benny Pedersen wrote:
hope its not needed to do same with urls
We're received spam with non-.pw headers but .pw urls. I'm blocking (ie
scoring high) anything with .pw/ urls at the moment - it's so bad :-(
--
Cheers
Jason Haar
Information Security Manager, Trimble
As we've spoken about off-list, my boss is being very particular about
the
deployment of Bayes, and it sounds like one of his caveats is that we
don't
start from a blank database.
Starting from a blank database is quickest and safest.
If you start from someone else's database, your Bayes
Jason Haar skrev den 2013-05-09 09:43:
On 09/05/13 17:38, Benny Pedersen wrote:
hope its not needed to do same with urls
We're received spam with non-.pw headers but .pw urls. I'm blocking
(ie
scoring high) anything with .pw/ urls at the moment - it's so bad :-(
sorry i did not see this
Hi, why don't you collect a selection of spam and ham emails prior to
go live and use them to train the Bayes DB prior to go live. Then you
have a Bayes DB trained to your own data at time of go live...
thanks, Andy.
Quoting Andrew Talbot andrew.talbot.ownweb...@gmail.com:
Well, I
starlight.201...@binnacle.cx skrev den 2013-05-08 17:02:
Does anyone know what the story is with this?
perldoc Mail::SpamAssassin::Conf see trusted_networks and
internal_networks, default is 127.0.0.1, is you server on ipv6 ?, its
your responsely to add all your wan ips to this settings
At 10:55 5/9/2013 +0200, Benny Pedersen wrote:
starlight.201...@binnacle.cx skrev den 2013-05-08 17:02:
Does anyone know what the story is with this?
perldoc Mail::SpamAssassin::Conf see
trusted_networks and internal_networks,
default is 127.0.0.1
its your responsely to add all your wan
ips to
starlight.201...@binnacle.cx skrev den 2013-05-09 15:56:
Of course, otherwise why would it work
with the older 'sa-update' rules?
Perhaps you should read the original
query again.
spamassassin can guess, but it is not configured to know all defaults
that fits all servers out there, for
At 16:42 5/9/2013 +0200, Benny Pedersen wrote:
starlight.201...@binnacle.cx skrev den 2013-05-09 15:56:
Like I said, I put back the 2/22/2013
rules (2/23 was a typo) and it is working
again. Probably will just leave it
that way forever unless someone knows
what was broken by the
starlight.201...@binnacle.cx skrev den 2013-05-09 17:47:
spamassassin 21 -D -t msg
on both versions should show what happen
Ran this and the problem is not reproducible
with the command-line SA invocation. Only
fails running under MimeDefang.
then report this to mimedefang maillist, and
Seems to me that since the only moving
part is the SA rules in /var/lib/spamassassin/3.003002
that it's a SA problem. If a way to run
that debug when SA is invoked by mimedefang
exists I'll do that.
Otherwise I'm done. Will just leave
the old rules in place. Only using SA
for URIBL checks
Figured it out--silly problem.
Overlooked setting 'umask 022' before running
'sa-update' and so the permission were
all set to 750 instead of 755. SA runs
in a restricted UID and so could not read
the files. Scored my test-to-self message
0 since none of the rules were working.
Seems odd to me
On 5/9/2013 1:29 PM, starlight.201...@binnacle.cx wrote:
Figured it out--silly problem.
Overlooked setting 'umask 022' before running
'sa-update' and so the permission were
all set to 750 instead of 755. SA runs
in a restricted UID and so could not read
the files. Scored my test-to-self
12 matches
Mail list logo
