You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Massimiliano Giovine <ev...@gmail.com> on 2010/06/21 23:41:57 UTC
Whitelist programmatically
Hi all.
I need to programmatically put one or more address into whitelist. How
can i do it?
Thanks in advance.
--
-Massimiliano Giovine
Re: Whitelist programmatically
Posted by Benny Pedersen <me...@junc.org>.
On man 21 jun 2010 23:41:57 CEST, Massimiliano Giovine wrote
> I need to programmatically put one or more address into whitelist. How
> can i do it?
perldoc Mail::SpamAssassin::Conf
perldoc Mail::SpamAssassin::Plugin::Freemail
perldoc Mail::SpamAssassin::Plugin::SPF
perldoc Mail::SpamAssassin::Plugin::DKIM
more ?
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: Whitelist programmatically
Posted by Massimiliano Giovine <ev...@gmail.com>.
Really thanks for the answers.
So, i need to configure my spamassassin installation to use the
running database (i'm already using a mysql database for other reason)
for whitelisting or i have to write the logic of a whitelist using my
database installationa?
Is there something i can read to go deep into this argument?
2010/6/22 Martin Gregorie <ma...@gregorie.org>:
> On Mon, 2010-06-21 at 23:41 +0200, Massimiliano Giovine wrote:
>> Hi all.
>>
>> I need to programmatically put one or more address into whitelist. How
>> can i do it?
>>
> Put the whitelisted addresses into a table in an SQL database because it
> can be updated at any time without the need to restart anything and can
> be implemented without any programming unless you want a fancy updating
> tool.
>
> Some (most?) MTAs can access the table directly, e.g. Postfix.
>
> Or you can write an SA plugin to interrogate the whitelist table.
>
> As an example of what you can do with a database-based approach, I'm
> running a mail archiving system that stores archived mail in a
> PostgresQL database. This doubles as a whitelist: anybody who is
> recorded in the database as a recipient of outbound mail is
> automatically a member of the whitelist.
>
>
> Martin
>
>
>
>
--
-Massimiliano Giovine
Aksel Peter Jørgensen dice: "Why make things difficult, when it is
possible to make them cryptic and totally illogic, with just a little
bit more effort?"
Blog: http://opentalking.blogspot.com
"Linus Torvalds doesn't die, he simply returns zero."
Re: Whitelist programmatically
Posted by Charles Gregory <cg...@hwcn.org>.
On Sat, 26 Jun 2010, Massimiliano Giovine wrote:
> You guessed right!
> It's a little bit more complicated but the target is what you said!
> If i write into user_prefs i have to restart spamassassin service?
Hmmmm.... Not sure about that one. I know you have to restart spamd for
changes to the site-wide config, but it wouldn't make sense to have to
restart for every user change....
Easy enough to test out... Make some changes and see if they take.
So, what are the complicated bits? :)
-C
>
> 2010/6/26 Charles Gregory <cg...@hwcn.org>:
>> On Sat, 26 Jun 2010, Massimiliano Giovine wrote:
>>>
>>> What does it do? How can i read the documentation of the spamassassin
>>> behavior with whitelisting?
>>
>> Firstly, the behaviour of the various whitelist options are described in the
>> Mail::SpamAssassin::Conf documentation. There is a copy on the web
>> at:
>>
>> http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html
>>
>> Now I have to ask what functionality you are trying to achieve that is not
>> already in SA? Are you simply trying to give your users a 'friendly' way to
>> add whitelist entries to their spamassassin config?
>>
>> If so, and the volume of entries is not large, I would suggest you use an
>> 'include whitelistfile' command in the user's .spamassassin/user_prefs and
>> then use whatever user interface you like to put a listing of whitelist
>> commands into that file.... Using a separate file would avoid issues with a
>> script error corrupting the main user_prefs file.
>>
>> - Charles
>>
>>
>>> 2010/6/22 Martin Gregorie <ma...@gregorie.org>:
>>>>
>>>> On Tue, 2010-06-22 at 07:28 +0200, Massimiliano Giovine wrote:
>>>>>
>>>>> Really thanks for the answers.
>>>>> So, i need to configure my spamassassin installation to use the
>>>>> running database (i'm already using a mysql database for other reason)
>>>>> for whitelisting or i have to write the logic of a whitelist using my
>>>>> database installationa?
>>>>>
>>>> You can do it all in SA. The steps are:
>>>>
>>>> 1)add another table to the database. This need only have a single column
>>>> that contains the list of e-mail addresses you want to whitelist.
>>>> The column needs to be the prime key, which is normally indexed.
>>>> The e-mail address needs to be indexed for good performance.
>>>>
>>>> 2)you need a way of adding addresses to the table. If you're happy to
>>>> use SQL you can use the MySQL interactive SQL tool or wrap it
>>>> in a shell script to implement a shell command like
>>>>
>>>> whitelist somebody@example.com"
>>>>
>>>> 3)of course you need some form of backup, but MySQL's standard database
>>>> backup and restore tools should do just fine. If you already have
>>>> a whitelist, you can easily load it into the database with the MySQL
>>>> bulk loader.
>>>>
>>>> 4)you need to write or otherwise obtain a Spamassassin plugin to access
>>>> the database and a rule to call the plugin.
>>>>
>>>> My whitelisting plugin interrogates a database view containing a
>>>> moderately complex query. This appears to the plugin as the sort of
>>>> table I've just described. If I was implementing your plugin I'd:
>>>>
>>>> - define a table that uses my view name as the table name and contains
>>>> the same column name. This way I could use my existing plugin to
>>>> access the whitelist table without any SQL changes, i.e.
>>>>
>>>> create table whitelist ( email varchar(80) primary key );
>>>>
>>>> - Modify my plugin to work with MySQL. I use PostgresQL as my database
>>>> but I think the changes would be minimal - possibly little more than
>>>> configuration changes. I've never used MySQL, so can't be more
>>>> definite.
>>>>
>>>>> Is there something i can read to go deep into this argument?
>>>>>
>>>> There isn't a lot. There's an SA document about writing plugins, which
>>>> is quite helpful. I found it was easy enough to read that and then grab
>>>> a plugin that accessed a database and modify that, but I do know some
>>>> Perl and understand object-oriented programming. You need both to
>>>> successfully create a plugin without too much trial and error. I found
>>>> that figuring out the database access was easy enough, but the SA
>>>> facility for configuring a plugin, i.e. telling it what sort of database
>>>> to access and where to find it, was poorly documented and did need quite
>>>> a bit of experimentation to get right.
>>>>
>>>> Caveat: As I've never used MySQL the preceding description assumes that
>>>> it has all the tools that come as standard with every other SQL database
>>>> I've used.
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> -Massimiliano Giovine
>>> Aksel Peter Jørgensen dice: "Why make things difficult, when it is
>>> possible to make them cryptic and totally illogic, with just a little
>>> bit more effort?"
>>> Blog: http://opentalking.blogspot.com
>>> "Linus Torvalds doesn't die, he simply returns zero."
>>
>
>
>
> --
> -Massimiliano Giovine
> Aksel Peter Jørgensen dice: "Why make things difficult, when it is
> possible to make them cryptic and totally illogic, with just a little
> bit more effort?"
> Blog: http://opentalking.blogspot.com
> "Linus Torvalds doesn't die, he simply returns zero."
>
Re: Whitelist programmatically
Posted by Massimiliano Giovine <ev...@gmail.com>.
You guessed right!
It's a little bit more complicated but the target is what you said!
If i write into user_prefs i have to restart spamassassin service?
2010/6/26 Charles Gregory <cg...@hwcn.org>:
> On Sat, 26 Jun 2010, Massimiliano Giovine wrote:
>>
>> What does it do? How can i read the documentation of the spamassassin
>> behavior with whitelisting?
>
> Firstly, the behaviour of the various whitelist options are described in the
> Mail::SpamAssassin::Conf documentation. There is a copy on the web
> at:
>
> http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html
>
> Now I have to ask what functionality you are trying to achieve that is not
> already in SA? Are you simply trying to give your users a 'friendly' way to
> add whitelist entries to their spamassassin config?
>
> If so, and the volume of entries is not large, I would suggest you use an
> 'include whitelistfile' command in the user's .spamassassin/user_prefs and
> then use whatever user interface you like to put a listing of whitelist
> commands into that file.... Using a separate file would avoid issues with a
> script error corrupting the main user_prefs file.
>
> - Charles
>
>
>> 2010/6/22 Martin Gregorie <ma...@gregorie.org>:
>>>
>>> On Tue, 2010-06-22 at 07:28 +0200, Massimiliano Giovine wrote:
>>>>
>>>> Really thanks for the answers.
>>>> So, i need to configure my spamassassin installation to use the
>>>> running database (i'm already using a mysql database for other reason)
>>>> for whitelisting or i have to write the logic of a whitelist using my
>>>> database installationa?
>>>>
>>> You can do it all in SA. The steps are:
>>>
>>> 1)add another table to the database. This need only have a single column
>>> that contains the list of e-mail addresses you want to whitelist.
>>> The column needs to be the prime key, which is normally indexed.
>>> The e-mail address needs to be indexed for good performance.
>>>
>>> 2)you need a way of adding addresses to the table. If you're happy to
>>> use SQL you can use the MySQL interactive SQL tool or wrap it
>>> in a shell script to implement a shell command like
>>>
>>> whitelist somebody@example.com"
>>>
>>> 3)of course you need some form of backup, but MySQL's standard database
>>> backup and restore tools should do just fine. If you already have
>>> a whitelist, you can easily load it into the database with the MySQL
>>> bulk loader.
>>>
>>> 4)you need to write or otherwise obtain a Spamassassin plugin to access
>>> the database and a rule to call the plugin.
>>>
>>> My whitelisting plugin interrogates a database view containing a
>>> moderately complex query. This appears to the plugin as the sort of
>>> table I've just described. If I was implementing your plugin I'd:
>>>
>>> - define a table that uses my view name as the table name and contains
>>> the same column name. This way I could use my existing plugin to
>>> access the whitelist table without any SQL changes, i.e.
>>>
>>> create table whitelist ( email varchar(80) primary key );
>>>
>>> - Modify my plugin to work with MySQL. I use PostgresQL as my database
>>> but I think the changes would be minimal - possibly little more than
>>> configuration changes. I've never used MySQL, so can't be more
>>> definite.
>>>
>>>> Is there something i can read to go deep into this argument?
>>>>
>>> There isn't a lot. There's an SA document about writing plugins, which
>>> is quite helpful. I found it was easy enough to read that and then grab
>>> a plugin that accessed a database and modify that, but I do know some
>>> Perl and understand object-oriented programming. You need both to
>>> successfully create a plugin without too much trial and error. I found
>>> that figuring out the database access was easy enough, but the SA
>>> facility for configuring a plugin, i.e. telling it what sort of database
>>> to access and where to find it, was poorly documented and did need quite
>>> a bit of experimentation to get right.
>>>
>>> Caveat: As I've never used MySQL the preceding description assumes that
>>> it has all the tools that come as standard with every other SQL database
>>> I've used.
>>>
>>>
>>> Martin
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> -Massimiliano Giovine
>> Aksel Peter Jørgensen dice: "Why make things difficult, when it is
>> possible to make them cryptic and totally illogic, with just a little
>> bit more effort?"
>> Blog: http://opentalking.blogspot.com
>> "Linus Torvalds doesn't die, he simply returns zero."
>
--
-Massimiliano Giovine
Aksel Peter Jørgensen dice: "Why make things difficult, when it is
possible to make them cryptic and totally illogic, with just a little
bit more effort?"
Blog: http://opentalking.blogspot.com
"Linus Torvalds doesn't die, he simply returns zero."
Re: Whitelist programmatically
Posted by Charles Gregory <cg...@hwcn.org>.
On Sat, 26 Jun 2010, Massimiliano Giovine wrote:
> What does it do? How can i read the documentation of the spamassassin
> behavior with whitelisting?
Firstly, the behaviour of the various whitelist options are described in
the Mail::SpamAssassin::Conf documentation. There is a copy on the web
at:
http://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html
Now I have to ask what functionality you are trying to achieve that is not
already in SA? Are you simply trying to give your users a 'friendly' way
to add whitelist entries to their spamassassin config?
If so, and the volume of entries is not large, I would suggest you use an
'include whitelistfile' command in the user's .spamassassin/user_prefs and
then use whatever user interface you like to put a listing of whitelist
commands into that file.... Using a separate file would avoid issues with
a script error corrupting the main user_prefs file.
- Charles
> 2010/6/22 Martin Gregorie <ma...@gregorie.org>:
>> On Tue, 2010-06-22 at 07:28 +0200, Massimiliano Giovine wrote:
>>> Really thanks for the answers.
>>> So, i need to configure my spamassassin installation to use the
>>> running database (i'm already using a mysql database for other reason)
>>> for whitelisting or i have to write the logic of a whitelist using my
>>> database installationa?
>>>
>> You can do it all in SA. The steps are:
>>
>> 1)add another table to the database. This need only have a single column
>> that contains the list of e-mail addresses you want to whitelist.
>> The column needs to be the prime key, which is normally indexed.
>> The e-mail address needs to be indexed for good performance.
>>
>> 2)you need a way of adding addresses to the table. If you're happy to
>> use SQL you can use the MySQL interactive SQL tool or wrap it
>> in a shell script to implement a shell command like
>>
>> whitelist somebody@example.com"
>>
>> 3)of course you need some form of backup, but MySQL's standard database
>> backup and restore tools should do just fine. If you already have
>> a whitelist, you can easily load it into the database with the MySQL
>> bulk loader.
>>
>> 4)you need to write or otherwise obtain a Spamassassin plugin to access
>> the database and a rule to call the plugin.
>>
>> My whitelisting plugin interrogates a database view containing a
>> moderately complex query. This appears to the plugin as the sort of
>> table I've just described. If I was implementing your plugin I'd:
>>
>> - define a table that uses my view name as the table name and contains
>> the same column name. This way I could use my existing plugin to
>> access the whitelist table without any SQL changes, i.e.
>>
>> create table whitelist ( email varchar(80) primary key );
>>
>> - Modify my plugin to work with MySQL. I use PostgresQL as my database
>> but I think the changes would be minimal - possibly little more than
>> configuration changes. I've never used MySQL, so can't be more
>> definite.
>>
>>> Is there something i can read to go deep into this argument?
>>>
>> There isn't a lot. There's an SA document about writing plugins, which
>> is quite helpful. I found it was easy enough to read that and then grab
>> a plugin that accessed a database and modify that, but I do know some
>> Perl and understand object-oriented programming. You need both to
>> successfully create a plugin without too much trial and error. I found
>> that figuring out the database access was easy enough, but the SA
>> facility for configuring a plugin, i.e. telling it what sort of database
>> to access and where to find it, was poorly documented and did need quite
>> a bit of experimentation to get right.
>>
>> Caveat: As I've never used MySQL the preceding description assumes that
>> it has all the tools that come as standard with every other SQL database
>> I've used.
>>
>>
>> Martin
>>
>>
>>
>>
>
>
>
> --
> -Massimiliano Giovine
> Aksel Peter Jørgensen dice: "Why make things difficult, when it is
> possible to make them cryptic and totally illogic, with just a little
> bit more effort?"
> Blog: http://opentalking.blogspot.com
> "Linus Torvalds doesn't die, he simply returns zero."
>
Re: Whitelist programmatically
Posted by John Hardin <jh...@impsec.org>.
On Sat, 26 Jun 2010, Massimiliano Giovine wrote:
> I understood i have 2 ways:
>
> 1) use the conf whitelisting $permsgstatus->{conf}->{whitelist_from}
Don't use whitelist_from. it is too easy for a spammer to spoof.
> 2) use a database that contains whitelist address and 2 plugins: 1 to
> read and the other one to write.
3) whitelist in whatever glue passes messages to SA.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Your mouse has moved. Your Windows Operating System must be
relicensed due to this hardware change. Please contact Microsoft
to obtain a new activation key. If this hardware change results in
added functionality you may be subject to additional license fees.
Your system will now shut down. Thank you for choosing Microsoft.
-----------------------------------------------------------------------
8 days until the 234th anniversary of the Declaration of Independence
Re: Whitelist programmatically
Posted by Massimiliano Giovine <ev...@gmail.com>.
I understood i have 2 ways:
1) use the conf whitelisting $permsgstatus->{conf}->{whitelist_from}
2) use a database that contains whitelist address and 2 plugins: 1 to
read and the other one to write.
If i wrote a plugin to customize whitelist for recipient i'd use the
second way but i also need to write a plugin has the same behavior of
spamassassin+conf->whitelist_from.
What does it do? How can i read the documentation of the spamassassin
behavior with whitelisting?
Thanks again in advance!
2010/6/22 Martin Gregorie <ma...@gregorie.org>:
> On Tue, 2010-06-22 at 07:28 +0200, Massimiliano Giovine wrote:
>> Really thanks for the answers.
>> So, i need to configure my spamassassin installation to use the
>> running database (i'm already using a mysql database for other reason)
>> for whitelisting or i have to write the logic of a whitelist using my
>> database installationa?
>>
> You can do it all in SA. The steps are:
>
> 1)add another table to the database. This need only have a single column
> that contains the list of e-mail addresses you want to whitelist.
> The column needs to be the prime key, which is normally indexed.
> The e-mail address needs to be indexed for good performance.
>
> 2)you need a way of adding addresses to the table. If you're happy to
> use SQL you can use the MySQL interactive SQL tool or wrap it
> in a shell script to implement a shell command like
>
> whitelist somebody@example.com"
>
> 3)of course you need some form of backup, but MySQL's standard database
> backup and restore tools should do just fine. If you already have
> a whitelist, you can easily load it into the database with the MySQL
> bulk loader.
>
> 4)you need to write or otherwise obtain a Spamassassin plugin to access
> the database and a rule to call the plugin.
>
> My whitelisting plugin interrogates a database view containing a
> moderately complex query. This appears to the plugin as the sort of
> table I've just described. If I was implementing your plugin I'd:
>
> - define a table that uses my view name as the table name and contains
> the same column name. This way I could use my existing plugin to
> access the whitelist table without any SQL changes, i.e.
>
> create table whitelist ( email varchar(80) primary key );
>
> - Modify my plugin to work with MySQL. I use PostgresQL as my database
> but I think the changes would be minimal - possibly little more than
> configuration changes. I've never used MySQL, so can't be more
> definite.
>
>> Is there something i can read to go deep into this argument?
>>
> There isn't a lot. There's an SA document about writing plugins, which
> is quite helpful. I found it was easy enough to read that and then grab
> a plugin that accessed a database and modify that, but I do know some
> Perl and understand object-oriented programming. You need both to
> successfully create a plugin without too much trial and error. I found
> that figuring out the database access was easy enough, but the SA
> facility for configuring a plugin, i.e. telling it what sort of database
> to access and where to find it, was poorly documented and did need quite
> a bit of experimentation to get right.
>
> Caveat: As I've never used MySQL the preceding description assumes that
> it has all the tools that come as standard with every other SQL database
> I've used.
>
>
> Martin
>
>
>
>
--
-Massimiliano Giovine
Aksel Peter Jørgensen dice: "Why make things difficult, when it is
possible to make them cryptic and totally illogic, with just a little
bit more effort?"
Blog: http://opentalking.blogspot.com
"Linus Torvalds doesn't die, he simply returns zero."