Re: Problem installing sa on my pi 3b+
On Fri, 9 Apr 2021, spamassas...@mach2.franken.de wrote:
Am 07.04.2021 um 12:27 schrieb Antony Stone:
I am running said packet install from an internet tutorial.
Who wrote that tutorial and where does it point you to get the packages
from?
Antony.
Hmm, it says execute the following commands:
sudo apt-get update
sudo apt-get install spamassassin
Without any further params. How am I supposed to know where that command does
get its package from???
Christian
Christian,
Use the "apt show spamassassin" command to show the information about the
spamassassin package.
One of the lines of output will be something like:
APT-Sources: http://us.archive.ubuntu.com/ubuntu bionic-updates/main amd64
Packages
That will tell you the package repository that it's getting that particular
package from.
For more info about the collection of sources that 'apt' & 'apt-get' are using
look at the "sources.list" config files in /etc/apt/ directory.
HTH
Dave
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-05491256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Problem installing sa on my pi 3b+
Am 07.04.2021 um 12:27 schrieb Antony Stone: I am running said packet install from an internet tutorial. Who wrote that tutorial and where does it point you to get the packages from? Antony. Hmm, it says execute the following commands: sudo apt-get update sudo apt-get install spamassassin Without any further params. How am I supposed to know where that command does get its package from??? Christian
Re: Using spamassassin modules from a git repo
> To update SpamAssassin module from time to time from Git I am using
> Puppet/Ansible that will put the code in the right places.
> On simpler install I am using a Makefile like this one:
>
>
> install:
> pod2man Esp.pm >
> "/usr/share/man/man3p/Mail::SpamAssassin::Plugin::Esp.3p"
> perl -cw Esp.pm && podlint Esp.pm && cp Esp.{cf,pm,pre}
> /etc/mail/spamassassin/
>
>
> Then I can run git pull from the directory and run make install to copy all
> files to the correct places.
Thanks Giovanni, yes, this is what one would normally do, drop the
files into /etc/spamassassin (linked from /etc/mail/spamassassin on my
system).
This also solves my initial problem of git repo within git repo. But
it doesn't solve my desire to keep things in one place. It's true
that with this particular module the file names are the same. And
it's also true that the man page (if I wanted to be able to read it
with the man command) would need to go in a different place.
I do kind of like Tom Hendrikx idea of putting cloning the folder into
somewhere in /usr/local/etc and putting a modified pre file in
/etc/spamassassin/. But it's true it's not perfect.
The next step in this I suppose could be to build a deb or rpm file
around these contributed modules. But I doubt people are going to
want to build and maintain packages for each of the different
unix/linux/other OSs out there.
Maybe just recommending module developers to put in a simple Makefile
with an install and uninstall target? I don't know if that's the
right answer. It does feel like this should be a bit more admin
friendly, by that I mean it should be more than lore to know the right
way to install spamassassin modules in a maintainable way with a
system.
Thanks all for the answers here.
signature.asc
Description: PGP signature
Re: Using spamassassin modules from a git repo
On 4/8/21 7:51 PM, Bill Cole wrote:
>> So clearly it's not ideal to clone a spamassassin module into
>> /etc/spamassassin!
>>
>> I'm curious if someone has a clean solution here that allows updating
>> the module from time to time from git.
>
> That module? No. I have the utmost respect for and trust in Giovanni Bechis
> and use his code every day, but that module as it exists at Github is not
> structured to be used from a git checkout. The 4 significant files all
> properly belong in different places. The specific proper places would depend
> on how your Perl and SA installations were configured.
To update SpamAssassin module from time to time from Git I am using
Puppet/Ansible that will put the code in the right places.
On simpler install I am using a Makefile like this one:
install:
pod2man Esp.pm >
"/usr/share/man/man3p/Mail::SpamAssassin::Plugin::Esp.3p"
perl -cw Esp.pm && podlint Esp.pm && cp Esp.{cf,pm,pre}
/etc/mail/spamassassin/
Then I can run git pull from the directory and run make install to copy all
files to the correct places.
Giovanni
OpenPGP_signature
Description: OpenPGP digital signature
Re: Using spamassassin modules from a git repo
On 8 Apr 2021, at 5:05, Michael Grant wrote: I'm running debian on my mail server. I use etckeeper to track changes in /etc. Often I run across modules such as spamassassin-esp and maybe I would consider playing with Jared Hall's CHAOS module. I'm curious what the recommended best practice is to install such modules from a git repo. Best practice? Don't. For spamassassin-esp, I cloned the repo into my /etc/spamassassin/ directory and then added this to my local.cf: Apart from anything specific to SpamAssassin, putting code under /etc/ is a bad practice. loadplugin Mail::SpamAssassin::Plugin::Esp spamassassin-esp/Esp.pm include spamassassin-esp/Esp.cf This allows me to 'git pull' from this repository from time to time to update it. But it's not perfect, especially as I have local changes to Esp.cf. It's actually worse since I forked it to give back some changes but I'd say that's perhaps less usual. Furthermore, as I said, I use etckeeper and when I 'apt upgrade', I get constant warnings: modified: spamassassin/spamassassin-esp (modified content, untracked content) I'm not familiar with etckeeper but it seems like it is working as designed and that it may be designed for a purpose at odds with how you actually want to manage your system. So clearly it's not ideal to clone a spamassassin module into /etc/spamassassin! I'm curious if someone has a clean solution here that allows updating the module from time to time from git. That module? No. I have the utmost respect for and trust in Giovanni Bechis and use his code every day, but that module as it exists at Github is not structured to be used from a git checkout. The 4 significant files all properly belong in different places. The specific proper places would depend on how your Perl and SA installations were configured. I realize this may be more a debian question and I may post it on the debian-users list if I don't get any decent replies here. I expect this qualifies as an indecent reply... -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Using spamassassin modules from a git repo
On Thu, Apr 08, 2021 at 07:00:57PM +0200, Benny Pedersen wrote: > On 2021-04-08 18:54, Michael Grant wrote: > > > This may be a stupid question... but for a spamassassin module, for > > example spamassassin-esp, how would one normally "install" this so > > that it reads the .pre file? > > all content should be placed in same dir as local.cf > > and custom plugins should have there own .pre with the > loadplugin > > i think it works if Esp.cf is in same dir as local.cf > then there is no need to make include lines This is what I want to avoid which was the goal of my original post. 1. Many modules are from git repos and need to live in their own directory to be updated from time to time, 2. the /etc/spamassassin/ directory can get very messy if you just dump things in there. Hard to know what's what, it becomes impossible to maintain. So I don't see any alternative to keeping such modules in separate directories like this. Is there really no way to tell spamassassin where to look for such modules, like some sort of search path? I'm surprised if not, and if not, would something like this be a reasonable feature to add in the future? signature.asc Description: PGP signature
Re: Using spamassassin modules from a git repo
On 2021-04-08 18:54, Michael Grant wrote: This may be a stupid question... but for a spamassassin module, for example spamassassin-esp, how would one normally "install" this so that it reads the .pre file? all content should be placed in same dir as local.cf and custom plugins should have there own .pre with the loadplugin i think it works if Esp.cf is in same dir as local.cf then there is no need to make include lines
Re: Using spamassassin modules from a git repo
On Thu, Apr 08, 2021 at 04:11:25PM +0200, Benny Pedersen wrote: > On 2021-04-08 11:05, Michael Grant wrote: > > > loadplugin Mail::SpamAssassin::Plugin::Esp spamassassin-esp/Esp.pm > > include spamassassin-esp/Esp.cf > > loadplugin must not be in cf files, it belongs to pre files This may be a stupid question... but for a spamassassin module, for example spamassassin-esp, how would one normally "install" this so that it reads the .pre file? Putting modules in /usr/local/etc/spamassassin/ as Tom Hendrikx suggested. What I have at the moment now is a modified version of /etc/spamassassin/Esp.pre: loadplugin Mail::SpamAssassin::Plugin::Esp /usr/local/etc/spamassassin-esp/Esp.pm include /usr/local/etc/spamassassin-esp/Esp.cf Given that there is an Esp.pre in the spamassassin-esp folder, is there a way I would use that pre file directly? I mean, is there some way to add that folder to spamassassin's "path"? signature.asc Description: PGP signature
Re: google.com spam
On 2021-04-08 18:25, Matus UHLAR - fantomas wrote: Therefore it should work in 3.4.5 thanks. I wait until debian guys will push 3.4.5 to backports. will be 3.4.6, if debian is awake :-)
Re: google.com spam
Am 2021-04-08 17:46, schrieb Bill Cole:
On 8 Apr 2021, at 6:25, Matus UHLAR - fantomas wrote:
and there is no undef_whitelist_auth, and the unwhitelist_auth
does NOT work.
It does work in 3.4.5, although if you're not there yet I'd advise
waiting for 3.4.6.
See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7809
On 08.04.21 18:06, Michael Storz wrote:
Ok, there is a code change from 3.4.4 to 3.4.5
from 3.4.5
push (@cmds, {
command => 'unwhitelist_auth',
setting => 'whitelist_auth',
type => $CONF_TYPE_ADDRLIST,
code => \::SpamAssassin::Conf::Parser::remove_addrlist_value
});
from 3.4.5
push (@cmds, {
setting => 'unwhitelist_auth',
type => $CONF_TYPE_ADDRLIST,
code => sub {
my ($self, $key, $value, $line) = @_;
unless (defined $value && $value !~ /^$/) {
return $MISSING_REQUIRED_VALUE;
}
unless ($value =~ /^(?:\S+(?:\s+\S+)*)$/) {
return $INVALID_VALUE;
}
$self->{parser}->remove_from_addrlist('whitelist_auth',
split (/\s+/, $value));
$self->{parser}->remove_from_addrlist('def_whitelist_auth',
split (/\s+/, $value));
}
});
Therefore it should work in 3.4.5
thanks. I wait until debian guys will push 3.4.5 to backports.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Nothing is fool-proof to a talented fool.
Re: google.com spam
Am 2021-04-08 17:46, schrieb Bill Cole:
On 8 Apr 2021, at 6:25, Matus UHLAR - fantomas wrote:
and there is no undef_whitelist_auth, and the unwhitelist_auth does
NOT work.
It does work in 3.4.5, although if you're not there yet I'd advise
waiting for 3.4.6.
See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7809
Ok, there is a code change from 3.4.4 to 3.4.5
from 3.4.5
push (@cmds, {
command => 'unwhitelist_auth',
setting => 'whitelist_auth',
type => $CONF_TYPE_ADDRLIST,
code => \::SpamAssassin::Conf::Parser::remove_addrlist_value
});
from 3.4.5
push (@cmds, {
setting => 'unwhitelist_auth',
type => $CONF_TYPE_ADDRLIST,
code => sub {
my ($self, $key, $value, $line) = @_;
unless (defined $value && $value !~ /^$/) {
return $MISSING_REQUIRED_VALUE;
}
unless ($value =~ /^(?:\S+(?:\s+\S+)*)$/) {
return $INVALID_VALUE;
}
$self->{parser}->remove_from_addrlist('whitelist_auth',
split (/\s+/, $value));
$self->{parser}->remove_from_addrlist('def_whitelist_auth',
split (/\s+/, $value));
}
});
Therefore it should work in 3.4.5
Michael
Re: google.com spam
Am 2021-04-08 17:26, schrieb Bill Cole:
On 8 Apr 2021, at 8:04, Matus UHLAR - fantomas wrote:
On Sun, 4 Apr 2021 13:21:08 +0200 Matus UHLAR - fantomas wrote:
I prefer to solve problems instead of playing with scores.
It seems that abusers have worked around SA by using google
domains
and addresses for sending spam from.
On 04.04.21 14:19, RW wrote:
If google have been foolish enough to allow abuse on the
organizational domain it should definitely be taken out of the def
whitelists until they move anything abusable to a different
subdomain/domain.
On Sun, 4 Apr 2021 16:47:18 +0200 Matus UHLAR - fantomas wrote:
That's what I'm trying to say.
And I'm agreeing. But I'm also saying that this kind of thing would
be
less of a problem if the 'def' whitelists were better organized.
For the
'def' whitelists to have any point they should be tuned to prevent
most such FPs while having a minimal impact on TPs. The rules are
scored far too strongly, but the fact they are additively scored
makes it impossible to fine tune them.
There's no point in additive scoring anyway. If any of them is hit
it's most likely the spam has gone through an abused server.
if you mean using combination of USER_IN_DEF_SPF_WL,
USER_IN_DEF_DKIM_WL and USER_IN_DEF_WELCOMELIST, they could be put
into if condition.
On 04.04.21 17:01, RW wrote:
I give them all a score of -0.001 and then score
USER_IN_DEF_WELCOMELIST || USER_IN_DEF_SPF_WL || USER_IN_DEF_DKIM_WL
...add USER_IN_DEF_WHITELIST there?
The way it's currently setup you could get a total def whitelist
score of -7.5, -15 -22.5 or -30, which is insane if you want there to
be a useful distinction between def and full whitelisting.
The worst part is that the commonest form, "def_whitelist_auth", is
scored separately for SPF and DKIM for a single whitelisting entry.
So
even if you avoid overlap with def_whitelist_from_rcvd, you still
have
this random N and 2N point scoring whatever you set N to.
I have just found that
def_whitelist_auth *@google.com
leads to:
USER_IN_DEF_DKIM_WL
...and since there's no undef_whitelist_from_auth, it sucks pretty
much and
I can only disable the whole rule because of google.
unwhitelist_auth exists. 'perldoc Mail::SpamAssassin::Conf' is helpful.
This removes entries from $conf->{'whitelist_auth'} but not from
$conf->{'def_whitelist_auth'}
In addition there is no delist_addrlist, therefore no chance to remove
an entry from def_whitelist_auth.
Michael
Re: google.com spam
On 8 Apr 2021, at 6:25, Matus UHLAR - fantomas wrote: and there is no undef_whitelist_auth, and the unwhitelist_auth does NOT work. It does work in 3.4.5, although if you're not there yet I'd advise waiting for 3.4.6. See https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7809 -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: google.com spam
On 8 Apr 2021, at 8:04, Matus UHLAR - fantomas wrote: On Sun, 4 Apr 2021 13:21:08 +0200 Matus UHLAR - fantomas wrote: > I prefer to solve problems instead of playing with scores. > > It seems that abusers have worked around SA by using google domains > and addresses for sending spam from. >>> >>> On 04.04.21 14:19, RW wrote: If google have been foolish enough to allow abuse on the organizational domain it should definitely be taken out of the def whitelists until they move anything abusable to a different subdomain/domain. > >> On Sun, 4 Apr 2021 16:47:18 +0200 Matus UHLAR - fantomas wrote: >>> That's what I'm trying to say. >> >> And I'm agreeing. But I'm also saying that this kind of thing would be >> less of a problem if the 'def' whitelists were better organized. > > For the 'def' whitelists to have any point they should be tuned to prevent most such FPs while having a minimal impact on TPs. The rules are scored far too strongly, but the fact they are additively scored makes it impossible to fine tune them. There's no point in additive scoring anyway. If any of them is hit it's most likely the spam has gone through an abused server. >>> >>> if you mean using combination of USER_IN_DEF_SPF_WL, >>> USER_IN_DEF_DKIM_WL and USER_IN_DEF_WELCOMELIST, they could be put >>> into if condition. > > On 04.04.21 17:01, RW wrote: >> I give them all a score of -0.001 and then score >> >> USER_IN_DEF_WELCOMELIST || USER_IN_DEF_SPF_WL || USER_IN_DEF_DKIM_WL > > ...add USER_IN_DEF_WHITELIST there? > >> The way it's currently setup you could get a total def whitelist >> score of -7.5, -15 -22.5 or -30, which is insane if you want there to >> be a useful distinction between def and full whitelisting. >> >> The worst part is that the commonest form, "def_whitelist_auth", is >> scored separately for SPF and DKIM for a single whitelisting entry. So >> even if you avoid overlap with def_whitelist_from_rcvd, you still have >> this random N and 2N point scoring whatever you set N to. > > I have just found that > > def_whitelist_auth *@google.com > > leads to: > > USER_IN_DEF_DKIM_WL > > ...and since there's no undef_whitelist_from_auth, it sucks pretty much and > I can only disable the whole rule because of google. unwhitelist_auth exists. 'perldoc Mail::SpamAssassin::Conf' is helpful. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Using spamassassin modules from a git repo
On 2021-04-08 11:05, Michael Grant wrote: loadplugin Mail::SpamAssassin::Plugin::Esp spamassassin-esp/Esp.pm include spamassassin-esp/Esp.cf loadplugin must not be in cf files, it belongs to pre files
Re: google.com spam
>On Sun, 4 Apr 2021 13:21:08 +0200 Matus UHLAR - fantomas wrote: >> I prefer to solve problems instead of playing with scores. >> >> It seems that abusers have worked around SA by using google domains >> and addresses for sending spam from. On 04.04.21 14:19, RW wrote: >If google have been foolish enough to allow abuse on the >organizational domain it should definitely be taken out of the def >whitelists until they move anything abusable to a different >subdomain/domain. On Sun, 4 Apr 2021 16:47:18 +0200 Matus UHLAR - fantomas wrote: That's what I'm trying to say. And I'm agreeing. But I'm also saying that this kind of thing would be less of a problem if the 'def' whitelists were better organized. > For the >'def' whitelists to have any point they should be tuned to prevent >most such FPs while having a minimal impact on TPs. The rules are >scored far too strongly, but the fact they are additively scored >makes it impossible to fine tune them. > >There's no point in additive scoring anyway. If any of them is hit >it's most likely the spam has gone through an abused server. if you mean using combination of USER_IN_DEF_SPF_WL, USER_IN_DEF_DKIM_WL and USER_IN_DEF_WELCOMELIST, they could be put into if condition. On 04.04.21 17:01, RW wrote: I give them all a score of -0.001 and then score USER_IN_DEF_WELCOMELIST || USER_IN_DEF_SPF_WL || USER_IN_DEF_DKIM_WL ...add USER_IN_DEF_WHITELIST there? The way it's currently setup you could get a total def whitelist score of -7.5, -15 -22.5 or -30, which is insane if you want there to be a useful distinction between def and full whitelisting. The worst part is that the commonest form, "def_whitelist_auth", is scored separately for SPF and DKIM for a single whitelisting entry. So even if you avoid overlap with def_whitelist_from_rcvd, you still have this random N and 2N point scoring whatever you set N to. I have just found that def_whitelist_auth *@google.com leads to: USER_IN_DEF_DKIM_WL ...and since there's no undef_whitelist_from_auth, it sucks pretty much and I can only disable the whole rule because of google. I can guess that USER_IN_DEF_WHITELIST only applies for def_whitelist_from and def_whitelist_from_rcvd which are used for mail without SPF/DKIM authentication. which then makes even less sense to give it -15 while authenticated whitelists have -7.5 I have an idea how to rewrite them, will post later. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux is like a teepee: no Windows, no Gates and an apache inside...
Re: google.com spam
On 04 Apr 2021, at 05:21, Matus UHLAR - fantomas wrote: I prefer to solve problems instead of playing with scores. On 04.04.21 06:35, @lbutlr wrote: The way that SA solves problems is by changing score values. The entire foundation of SA is "playing with scores". I disagree. The main work is on "playing with rules". Unfortunately, the problem is: def_whitelist_auth *@google.com and there is no undef_whitelist_auth, and the unwhitelist_auth does NOT work. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
Re: Using spamassassin modules from a git repo
How about cloning outside your etc directory, for instance in /usr/local? And then adding the correct paths to local.cf, as usual. Kind regards, Tom On 08-04-2021 11:05, Michael Grant wrote: I'm running debian on my mail server. I use etckeeper to track changes in /etc. Often I run across modules such as spamassassin-esp and maybe I would consider playing with Jared Hall's CHAOS module. I'm curious what the recommended best practice is to install such modules from a git repo. For spamassassin-esp, I cloned the repo into my /etc/spamassassin/ directory and then added this to my local.cf: loadplugin Mail::SpamAssassin::Plugin::Esp spamassassin-esp/Esp.pm include spamassassin-esp/Esp.cf This allows me to 'git pull' from this repository from time to time to update it. But it's not perfect, especially as I have local changes to Esp.cf. It's actually worse since I forked it to give back some changes but I'd say that's perhaps less usual. Furthermore, as I said, I use etckeeper and when I 'apt upgrade', I get constant warnings: modified: spamassassin/spamassassin-esp (modified content, untracked content) So clearly it's not ideal to clone a spamassassin module into /etc/spamassassin! I'm curious if someone has a clean solution here that allows updating the module from time to time from git. I realize this may be more a debian question and I may post it on the debian-users list if I don't get any decent replies here. Michael Grant
Using spamassassin modules from a git repo
I'm running debian on my mail server. I use etckeeper to track changes in /etc. Often I run across modules such as spamassassin-esp and maybe I would consider playing with Jared Hall's CHAOS module. I'm curious what the recommended best practice is to install such modules from a git repo. For spamassassin-esp, I cloned the repo into my /etc/spamassassin/ directory and then added this to my local.cf: loadplugin Mail::SpamAssassin::Plugin::Esp spamassassin-esp/Esp.pm include spamassassin-esp/Esp.cf This allows me to 'git pull' from this repository from time to time to update it. But it's not perfect, especially as I have local changes to Esp.cf. It's actually worse since I forked it to give back some changes but I'd say that's perhaps less usual. Furthermore, as I said, I use etckeeper and when I 'apt upgrade', I get constant warnings: modified: spamassassin/spamassassin-esp (modified content, untracked content) So clearly it's not ideal to clone a spamassassin module into /etc/spamassassin! I'm curious if someone has a clean solution here that allows updating the module from time to time from git. I realize this may be more a debian question and I may post it on the debian-users list if I don't get any decent replies here. Michael Grant signature.asc Description: PGP signature
Re: uribl result not triggering meta rule
On 02/04/2021 13:46, Wolfgang Breyha wrote: Hi! It seems that 3.4.5 changed the behavior of URIBL lookups in a quite bad way compared to 3.4.4. Just as a pointer: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7897 Greetings, Wolfgang
Re: CHAOS v1.1.1
On 07.04.21 14:40, Jared Hall wrote: Released Apr 7, 2021 - Better Unibabble bibber-blabber blockage. - Improved Title Case sort order. - Tons of new callouts added to the mailer_check(). - MailChimp header and MS Exchange header spoofing sanity checks. - Added Microsoft Cab files to the attachment checks. https://github.com/telecom2k3/CHAOS May your days be long and without bifurcation. could you please finally try to explain what does that do, without buzzwords? And, probably, answer our questions about that? Because, for now, the whole CHAOS looks like unexplainable and hardly understandable mess. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I feel like I'm diagonally parked in a parallel universe.
