Mailing List Archive

google.com spam
Hello,

I have received spam from:

From: "Linda marry (via Google Drive)" <drive-shares-noreply@google.com>

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.0000]
* 4.0 BAYES_99 BODY: Bayes spam probability is 99 to 100%
* [score: 1.0000]
* -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_2tld google.com



--
Matus UHLAR - fantomas, uhlar@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.
Re: google.com spam [ In reply to ]
On 2021-04-04 12:54, Matus UHLAR - fantomas wrote:
> Hello,
>
> I have received spam from:
>
> From: "Linda marry (via Google Drive)"
> <drive-shares-noreply@google.com>
>
> 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.0000]
> * 4.0 BAYES_99 BODY: Bayes spam probability is 99 to 100%
> * [score: 1.0000]
> * -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_2tld google.com


seems working
Re: google.com spam [ In reply to ]
>On 2021-04-04 12:54, Matus UHLAR - fantomas wrote:
>>I have received spam from:
>>
>>From: "Linda marry (via Google Drive)"
>><drive-shares-noreply@google.com>
>>
>>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, uhlar@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 [ In reply to ]
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 [ In reply to ]
On 04 Apr 2021, at 05:21, Matus UHLAR - fantomas <uhlar@fantomas.sk> 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 [ In reply to ]
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 [ In reply to ]
>> 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, uhlar@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 [ In reply to ]
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 [ In reply to ]
An update to this:

On 04.04.21 12:54, Matus UHLAR - fantomas wrote:
>I have received spam from:
>
>From: "Linda marry (via Google Drive)" <drive-shares-noreply@google.com>
>
>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]

> * -7.5 USER_IN_DEF_DKIM_WL From: address is in the default DKIM
> * white-list


I see they are evolving now, using google redirects to google links, further
hiding.

Subject: Husband is outside from home for two month
From: "Sarah Babe (via Google Docs)" <drive-shares-noreply@google.com>

[1]sarah@bestusaproduct.com has attached the following document:
Husband is outside from home for two month
Snapshot of the item below:

First time attempting this. He will NOT be present. Husband is outside from home
for two month. Seeking a horny guys who like blow job. Will be at my apartment.
I'm game for whatever. No I'm not going to ask you to go to another site. If U
real hit me on my [2]Facebook Profile.I will call you after add me.

My Pic, Videos Number and details Here: [3]Login

After submit your email checks the spam or inbox massage, to get my phone
number.


Google Docs: Create and edit documents online.
Google LLC, 1600 Amphitheatre Parkway, Mountain View,
CA 94043, USA [5]Logo for Google
You have received this email because Docs
[4]sarah@bestusaproduct.com shared a document with you
from Google Docs.

References

Visible links
1. mailto:sarah@bestusaproduct.com
2. https://www.google.com/url?q=https://sites.google.com/view/privatedate0/home&sa=D&source=editors&ust=1617657716510000&usg=AOvVaw30LDkVa5l018jaWFV4lSAv
3. https://www.google.com/url?q=https://sites.google.com/view/privatedate0/home&sa=D&source=editors&ust=1617657716511000&usg=AOvVaw1vJ3q82cTvOBs37YX7kXUX
4. mailto:sarah@bestusaproduct.com
5. http://drive.google.com/

--
Matus UHLAR - fantomas, uhlar@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 say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."
Re: google.com spam [ In reply to ]
Matus UHLAR - fantomas wrote:
> I see they are evolving now, using google redirects to google links,
> further
> hiding.

> https://www.google.com/url?q=https://sites.google.com/

I've just created local rules to give a few points to several such
constructs ranging from a low-scoring hit on just having http(s) more
than once in the URI to various explicit pairs of Google Service A ->
Google Service B. I've also handed out a few 0.5 scores just for
hitting any one of those services.

I've also been targeting (ab)use of the "data-saferedirecturl" attribute
in <a> tags because for the life of me I can NOT figure out what valid
use case it has that can't be (and as best I can tell, absolutely IS)
trivially abused. I'm eyeing the "title" attribute much the same way;
both appear to interfere with what shows up in the lower-left corner of
the screen to show where the link is supposedly going. IMO if that
popup/status bar info does NOT show the exact URL from the href
attribute, that client is Doing It Wrong.

-kgd
Re: google.com spam [ In reply to ]
>On 04 Apr 2021, at 05:21, Matus UHLAR - fantomas <uhlar@fantomas.sk> 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, uhlar@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: google.com spam [ In reply to ]
>> >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, uhlar@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 [ In reply to ]
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: google.com spam [ In reply to ]
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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
Re: google.com spam [ In reply to ]
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 [ In reply to ]
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 => \&Mail::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 [ In reply to ]
>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 => \&Mail::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, uhlar@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 [ In reply to ]
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 :-)