Re: Update SA on CentOS
- Message from Bill Cole - Date: Sun, 04 Apr 2021 15:16:32 -0400 From: Bill Cole Subject: Re: Update SA on CentOS To: users@spamassassin.apache.org On 4 Apr 2021, at 0:19, Simon Wilson wrote: CentOS / RHEL backport critical security fixes into the stock versions... you lose that as soon as you go 'roll-your-own'. Not a real feature IF you're keeping up with SA releases. Arguably an anti-feature. Critical security fixes for SA are integrated into minor version releases (such as in 3.4.5) and are not assured of being backportable onto any version of SA older than the live 'HEAD' of the development branch when the security fix is committed. Put another way, RedHat cherry-picks code changes (security and bugfix) that may not be fully independent of the other changes made between releases. They may be creating versions that have subtle breakage that no canonical release or even point-in-time development HEAD snapshot shares. Hi Bill, You may be absolutely correct - I don't know. Are there documented examples of the breaks you speak of? Running 3.4.2 on RHEL8 I'd be interested to know. But that does somewhat miss my point - which for the topic posted was that understanding *exactly what the problem is* and then working out what may address it makes more sense than jumping *first* to a roll-your-own on an OS with a design strategy such as CentOS. Simon. ___ Simon Wilson M: 0400 12 11 16
Problem installing sa on my pi 3b+
Hi there, when running a 'sudo apt-get install spamassassin' on my raspian pi 3b+ i keep running into a problem with sa-compile: sa-compile (3.4.2-1+deb10u3) wird eingerichtet ... Running sa-compile (may take a long time) In file included from /usr/lib/arm-linux-gnueabihf/perl/5.28/CORE/perl.h:702, from body_0.xs:2: /usr/include/ctype.h: In function ‘tolower’: /usr/include/ctype.h:209:3: internal compiler error: Ungültiger Maschinenbefehl return __c >= -128 && __c < 256 ? (*__ctype_tolower_loc ())[__c] : __c; ^~ 0x76aff11f ??? ../sysdeps/unix/sysv/linux/arm/sigrestorer.S:64 0x76ae9717 __libc_start_main /build/glibc-FUvrFr/glibc-2.28/csu/libc-start.c:308 Can anyone give me a hint what to do? I am rather new to this so other than running some packet installs i've done nothing but working thru howto's. Kind regards Christian
Re: Update SA on CentOS
On 4 Apr 2021, at 0:19, Simon Wilson wrote: CentOS / RHEL backport critical security fixes into the stock versions... you lose that as soon as you go 'roll-your-own'. Not a real feature IF you're keeping up with SA releases. Arguably an anti-feature. Critical security fixes for SA are integrated into minor version releases (such as in 3.4.5) and are not assured of being backportable onto any version of SA older than the live 'HEAD' of the development branch when the security fix is committed. Put another way, RedHat cherry-picks code changes (security and bugfix) that may not be fully independent of the other changes made between releases. They may be creating versions that have subtle breakage that no canonical release or even point-in-time development HEAD snapshot shares. -- 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 Sun, 4 Apr 2021 16:47:18 +0200 Matus UHLAR - fantomas wrote: > >> On 04.04.21 13:09, Benny Pedersen wrote: > >> >change score to 7.5 > >> >change score to -3.5 > > >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. > > 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. 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 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.
Re: google.com spam
On 04.04.21 13:09, Benny Pedersen wrote: >change score to 7.5 >change score to -3.5 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. That's what I'm trying to say. Their sites.google.com has been used for spam links for months, I just found the same account being used 4 times since Jan. I have reported allspam accounts but they were apparently kept alive. ...it's also why I put google.com into util_rb_2tld and clear_uridnsbl_skip_domain. However, the point about scores is a valid one in this case. of course, but as time advances, scores in SA are re-evaluated and changed, which I'm hoping for. even without that, changing one score can have strange results later with different mail, so any tuning should be handled with care. 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. Also, old syntas shoulx make those lists a bit less efficient, so this should be: score USER_IN_DEF_WELCOMELIST 0.01 score USER_IN_DEF_WHITELIST -15.0 instead of: score USER_IN_DEF_WELCOMELIST -0.01 score USER_IN_DEF_WHITELIST -15.0 -- 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. - Holmes, what kind of school did you study to be a detective? - Elementary, Watkins. -- Daffy Duck & Porky Pig
Re: google.com spam
On Sun, 4 Apr 2021 13:21:08 +0200 Matus UHLAR - fantomas wrote: > On 04.04.21 13:09, Benny Pedersen wrote: > >change score to 7.5 > >change score to -3.5 > > 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. 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. However, the point about scores is a valid one in this case. 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.
Re: google.com spam
On 04 Apr 2021, at 05:21, Matus UHLAR - fantomas wrote: > On 04.04.21 13:09, Benny Pedersen wrote: >> change score to 7.5 >> change score to -3.5 > > I prefer to solve problems instead of playing with scores. The way that SA solves problems is by changing score values. The entire foundation of SA is "playing with scores". -- It was not, it could not be real. But in the roaring air he knew that it was, for all who needed to believe, and in a belief so strong that truth was not the same as fact... he knew that for now, and yesterday, and tomorrow, both the thing, and the whole of the thing.
Re: google.com spam
On 2021-04-04 13:21, Matus UHLAR - fantomas wrote: On 04.04.21 13:09, Benny Pedersen wrote: change score to 7.5 change score to -3.5 I prefer to solve problems instead of playing with scores. first rule hits is local rule with imho to low score for problems on spamassassin rules :-) meta REAL_SPAM (BAYES_999 && L_URIBL_FANTOMAS) describe REAL_SPAM Meta: BAYES_999 && L_URIBL_FANTOMAS score REAL_SPAM 10 10 10 10 might do the trick of google spammers knowing opensource projects as spamassassin It seems that abusers have worked around SA by using google domains and addresses for sending spam from. is there a law that forbid it ?
Re: google.com spam
On 2021-04-04 12:54, Matus UHLAR - fantomas wrote: I have received spam from: From: "Linda marry (via Google Drive)" it wasn't catches because of: 60_whitelist_auth.cf:def_welcomelist_auth *@google.com Now that users can abuse google.com domain, isn't it time to remove *@google.com from def_whitelist_* ? the full header: X-Spam-Report: * 3.5 L_URIBL_FANTOMAS contains locally blocklisted URI * [URIs: sites.google.com] On 04.04.21 13:09, Benny Pedersen wrote: change score to 7.5 change score to -3.5 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. -- 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. Remember half the people you know are below average.
Re: google.com spam
On 2021-04-04 12:54, Matus UHLAR - fantomas wrote: Hello, I have received spam from: From: "Linda marry (via Google Drive)" it wasn't catches because of: 60_whitelist_auth.cf:def_welcomelist_auth *@google.com Now that users can abuse google.com domain, isn't it time to remove *@google.com from def_whitelist_* ? the full header: X-Spam-Report: * 3.5 L_URIBL_FANTOMAS contains locally blocklisted URI * [URIs: sites.google.com] change score to 7.5 * 0.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100% * [score: 1.] * 4.0 BAYES_99 BODY: Bayes spam probability is 99 to 100% * [score: 1.] * -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) * [209.85.167.206 listed in wl.mailspike.net] * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at * https://www.dnswl.org/, no trust * [209.85.167.206 listed in list.dnswl.org] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -7.5 USER_IN_DEF_DKIM_WL From: address is in the default DKIM * white-list change score to -3.5 * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * 1.0 GOOGLE_DRIVE_REPLY_BAD_NTLD From Google Drive and Reply-To is * from a suspicious TLD or add more score to this score GOOGLE_DRIVE_REPLY_BAD_NTLD (3) (3) (3) (3) will add 3 to masscheck scoreing I even have following in my local.cf to be able to carch google docs/drive/whatever spam via URIBL: clear_uridnsbl_skip_domain goo.gl google.com util_rb_2tldgoogle.com seems working
google.com spam
Hello, I have received spam from: From: "Linda marry (via Google Drive)" it wasn't catches because of: 60_whitelist_auth.cf:def_welcomelist_auth *@google.com Now that users can abuse google.com domain, isn't it time to remove *@google.com from def_whitelist_* ? the full header: X-Spam-Report: * 3.5 L_URIBL_FANTOMAS contains locally blocklisted URI * [URIs: sites.google.com] * 0.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100% * [score: 1.] * 4.0 BAYES_99 BODY: Bayes spam probability is 99 to 100% * [score: 1.] * -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) * [209.85.167.206 listed in wl.mailspike.net] * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at * https://www.dnswl.org/, no trust * [209.85.167.206 listed in list.dnswl.org] * -0.0 SPF_PASS SPF: sender matches SPF record * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -7.5 USER_IN_DEF_DKIM_WL From: address is in the default DKIM * white-list * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from * author's domain * 1.0 GOOGLE_DRIVE_REPLY_BAD_NTLD From Google Drive and Reply-To is * from a suspicious TLD I even have following in my local.cf to be able to carch google docs/drive/whatever spam via URIBL: clear_uridnsbl_skip_domain goo.gl google.com util_rb_2tldgoogle.com -- 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.
