You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Kjetil Kjernsmo <kj...@kjernsmo.net> on 2004/11/15 14:34:03 UTC
Priviliges on the Bayes DB
Hi all!
I'm just upgrading to 3.0.1, and I think I'd like to use a PostgreSQL
database for my Bayes DB. I'm setting it up with a user, and they say
it is a Good Idea to give this user the privileges it needs, no more,
no less. I couldn't find this documented anywhere (is it?), so I looked
through the sources of Mail::SpamAssassin::BayesStore::SQL last night,
and I came up with the following SQL:
CREATE USER thomasbayes WITH PASSWORD 'trustno1';
GRANT SELECT, UPDATE, DELETE, INSERT ON TABLE bayes_token TO
thomasbayes;
GRANT UPDATE, SELECT, DELETE, INSERT ON TABLE bayes_vars TO thomasbayes;
GRANT SELECT, INSERT, DELETE ON TABLE bayes_seen TO thomasbayes;
GRANT SELECT, INSERT, DELETE ON TABLE bayes_expire TO thomasbayes;
GRANT SELECT ON TABLE bayes_global_vars TO thomasbayes;
Pretty much, I just added privileges on tables as I encountered them in
the source... I don't really have a way to test this exhaustively, so
I'm wondering if someone can check it out...
BTW, if any Debian users here know a way to upgrade the libdb2 based
bayes db to Pg, I would be happy to hear about it... The usual and
documented upgrade path (dump to backup with sa-learn) is blocked,
because I have upgraded Perl. This is Debian bug #188997.
I could build a new corpus, but this db contains a collection of spam
and ham of mine back to antiquity and was very effective in the past...
Cheers,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kjetil@kjernsmo.net webmaster@skepsis.no editor@learn-orienteering.org
Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
Re: Priviliges on the Bayes DB
Posted by Kjetil Kjernsmo <kj...@kjernsmo.net>.
On mandag 15 november 2004, 14:34, Kjetil Kjernsmo wrote:
> GRANT SELECT, UPDATE, DELETE, INSERT ON TABLE bayes_token TO
> thomasbayes;
> GRANT UPDATE, SELECT, DELETE, INSERT ON TABLE bayes_vars TO
> thomasbayes; GRANT SELECT, INSERT, DELETE ON TABLE bayes_seen TO
> thomasbayes; GRANT SELECT, INSERT, DELETE ON TABLE bayes_expire TO
> thomasbayes; GRANT SELECT ON TABLE bayes_global_vars TO thomasbayes;
FWIW, I have found during testing that this isn't sufficient, I needed
at least
GRANT UPDATE, SELECT, DELETE, INSERT ON bayes_vars_id_seq TO
thomasbayes;
...too. This may be Pg-specific, though... Anything else...?
Cheers,
Kjetil
--
Kjetil Kjernsmo
Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer
kjetil@kjernsmo.net webmaster@skepsis.no editor@learn-orienteering.org
Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC
Re: Spam with ``=?utf-8?q?'' in From/To/Subject
Posted by Dave Sill <de...@sws5.ornl.gov>.
Excellent, thanks everyone. The :raw did the trick. I'm upgrading to
3.0, too.
-Dave
Re: Spam with ``=?utf-8?q?'' in From/To/Subject
Posted by Matt Kettler <mk...@evi-inc.com>.
At 09:19 AM 11/15/2004, Dave Sill wrote:
>From: =?utf-8?q?Hubert Lfa?= <dr...@stctoronto.xxx>
>To: =?utf-8?q?Eustace Oiw?= <tr...@sws1.ctd.ornl.xxx>
>Subject: =?utf-8?q?Economize 65 % or mo?=
> =?utf-8?q?re on our prescript?=
> =?utf-8?q?ions?=
>
>I tried adding rules (SA 2.63) to match "utf-8" in these fields, but
>they don't work--apparently SA is decoding them before applying the
>rules. There's no "rawheader" tag, and "full" seems to only include
>the body.
1) upgrade to 2.64 or higher as soon as practical. 2.63 is vulnerable to a
DoS attack if fed a malformed message. While a DoS isn't a huge security
risk, it can be a gigantic pain.
Upgrading to 2.64 should be pretty trivial, as the codebase is mostly the
same and the requirements are the same.
3.0.1 might be a steeper curve, but adds a lot of nice features if you
want/need them.
2) use the following syntax to force raw processing of headers:
header LOCAL_RAW_FROM From:raw =~ /Rawtext/
This syntax is documented in 3.0, but does appear to be supported in SA 2.64.
Re: Spam with ``=?utf-8?q?'' in From/To/Subject
Posted by Theo Van Dinter <fe...@kluge.net>.
On Mon, Nov 15, 2004 at 09:19:08AM -0500, Dave Sill wrote:
> rules. There's no "rawheader" tag, and "full" seems to only include
> the body.
Actually, there is a raw header specification:
header RULE Subject:raw =~ /.../
and yes, "full" will only do the body since it's short for "full body". ;)
--
Randomly Generated Tagline:
I know it's weird, but it does make it easier to write poetry in perl. :-)
-- Larry Wall in <78...@jpl-devvax.JPL.NASA.GOV>
Spam with ``=?utf-8?q?'' in From/To/Subject
Posted by Dave Sill <de...@sws5.ornl.gov>.
I'm getting lots of messages with UTF-8 encoding specified in the
header, e.g.:
From: =?utf-8?q?Hubert Lfa?= <dr...@stctoronto.xxx>
To: =?utf-8?q?Eustace Oiw?= <tr...@sws1.ctd.ornl.xxx>
Subject: =?utf-8?q?Economize 65 % or mo?=
=?utf-8?q?re on our prescript?=
=?utf-8?q?ions?=
I tried adding rules (SA 2.63) to match "utf-8" in these fields, but
they don't work--apparently SA is decoding them before applying the
rules. There's no "rawheader" tag, and "full" seems to only include
the body.
Is there any way to match these messages? I could upgrade this system
to 3.0 if that would help.
-Dave