bayes: no dbs present, cannot tie DB R/O

2017-01-29 Thread gladston3

Hello,

I use SpamAssassin version 3.4.1 with amavisd-new-2.10.1.
I reset my bayes db via "sa-learn --clear". After that spamassassin 
seems to be unable to create a new empty database. When I run "sa-learn 
--dump" I get the following error: `[1547] dbg: bayes: no dbs present, 
cannot tie DB R/O: /var/lib/amavis/.spamassassin/bayes_toks`
Since I am pretty sure that this cannot really be a permission issue, I 
set bayes_path to tmp where permissions are 777, tried again and got the 
very same error:

`[1565] dbg: bayes: no dbs present, cannot tie DB R/O: /tmp/bayes_toks `

So the problem seems to lie somewhere else. What else can I try to fix 
this?


Thank you very much in advance


Re: bayes: no dbs present, cannot tie DB R/O

2017-01-29 Thread RW
On Sun, 29 Jan 2017 20:05:29 +0100
gladst...@posteo.de wrote:

> Hello,
> 
> I use SpamAssassin version 3.4.1 with amavisd-new-2.10.1.
> I reset my bayes db via "sa-learn --clear". After that spamassassin 
> seems to be unable to create a new empty database. When I run
> "sa-learn --dump" I get the following error: `[1547] dbg: bayes: no
> dbs present, cannot tie DB
> R/O: /var/lib/amavis/.spamassassin/bayes_toks` Since I am pretty sure
> that this cannot really be a permission issue, I set bayes_path to
> tmp where permissions are 777, tried again and got the very same
> error: `[1565] dbg: bayes: no dbs present, cannot tie DB
> R/O: /tmp/bayes_toks `
> 
> So the problem seems to lie somewhere else. What else can I try to
> fix this?

The problem is that you are trying to read from a non-existent
database rather than write to it. 

$ sa-learn --backup > /tmp/bayes

$ sa-learn --clear

$ sa-learn --dump magic
ERROR: Bayes dump returned an error, please re-run with -D for more
information

$ printf "\n\nHello World\n" |  sa-learn --ham
Learned tokens from 1 message(s) (1 message(s) examined)

$ sa-learn --dump magic
0.000  0  3  0  non-token data: bayes db version
0.000  0  0  0  non-token data: nspam
0.000  0  1  0  non-token data: nham
...


Re: Legit Yahoo mail servers list

2017-01-29 Thread Dianne Skoll
On Sat, 28 Jan 2017 16:33:24 +
David Jones  wrote:

> Read back through this thread.  I never said their SPF record is
> invalid. All I said is their SPF record is not common and it makes it
> very hard for anyone to know what the official Yahoo outbound mail
> servers are.

Why is that important?  Can't you just whitelist the domain yahoo.com if
and only if it hits SPF "pass"?

> We have to work very hard to get our MTAs to whitelist
> them.  It's in their own best interest to make this information
> easily available to the Internet since so much spam comes out of
> their platform.

Then why would you whitelist them?

> They are too large to not whitelist.

Nobody is too large to not whitelist.  They're obviously too large to
block, but you'd be foolish to accept any and all mail from a Yahoo
server unless you like an awful lot of spam.

Regards,

Dianne.


Re: Legit Yahoo mail servers list

2017-01-29 Thread Rob McEwen

On 1/29/2017 7:42 PM, Dianne Skoll wrote:

On Sat, 28 Jan 2017 16:33:24 +
David Jones  wrote:


Read back through this thread.  I never said their SPF record is
invalid. All I said is their SPF record is not common and it makes it
very hard for anyone to know what the official Yahoo outbound mail
servers are.


Why is that important?  Can't you just whitelist the domain yahoo.com if
and only if it hits SPF "pass"?


We have to work very hard to get our MTAs to whitelist
them.  It's in their own best interest to make this information
easily available to the Internet since so much spam comes out of
their platform.


Then why would you whitelist them?


They are too large to not whitelist.


Nobody is too large to not whitelist.  They're obviously too large to
block, but you'd be foolish to accept any and all mail from a Yahoo
server unless you like an awful lot of spam.

Regards,

Dianne.




Dianne,

I can't speak for David, but most or all of your answers don't apply to 
my own anti-spam blacklist's attempt to try to avoid blacklisting Yahoo 
IPs that are both known for sending much spam, but which also would have 
a very high rate of collateral damage if blacklisted. (recognizing that 
some very good DNSBLs, which are more aggressive, are more willing to 
blacklist Yahoo IPs, and that isn't always a bad thing)


...and/or your answer requires more on-going receiver-side resources.

Interestingly, many senders would crawl over broken glass if necessary 
to provide me their IPs, if said I was seeking those for my whitelist.


Also, when David said "whitelist", I can take an educated guess that he 
isn't allowing Yahoo-sent messages free unfiltered access to the inbox - 
he is probably just trying to avoid DNSBL checking of those particular 
IPs - but then he'll probably STILL do other content filtering of those 
messages. That would be my educated guess. And this would be a SMART 
strategy.


Personally, when I get messages from Yahoo into my hosting business - I 
have the IPs generally not checked - since I already have most Yahoo IPs 
whitelisted - then I only content-check the messages - BUT... next I 
AMPLY any content scoring of such messages since these came from Yahoo 
and are more likely to be spam - that is, if the sender isn't already in 
a carefully cultivated exception list of known good Yahoo senders 
(specific to my mail hosting user base) - I do this for all freemail 
senders known to send a high volume of spam.


I know you mentioned that Yahoo may want to have the flexibility to 
change their IPs. But instead of providing a list, they could also 
provide a link to a web page listing the IPs (like what Comcast does) - 
and then just update that web page whenever their IPs change. This isn't 
rocket science.


As it stands, it is mind boggling just how many Yahoo ranges of sending 
IPs there are worldwide. Over the years, I've added 53 yahoo entries to 
my whitelist. Besides the hundreds and hundreds of /24s ranges in there 
(many are multiple consecutive /24s, showing up as just one line of 
those 53 entries), there are also several /16s, too. It would be nice to 
be able to compare that to Yahoo's current list active sending IPs (if 
such were available?), so that I could EFFICIENTLY update/prune that 
part of my whitelist.


And I strongly suspect that iterating though the millions of IPs to 
check FCrDNS would take a very, very long time - and might get such 
probing IPs blacklisted for abuse/intrusion-protection?


--
Rob McEwen