Re: Whitelist rules should never pass on SPF fail

[Noel Butler]

On 11/05/2024 03:40, Bill Cole wrote:

So what? domain owners state hard fail it SHOULD be hard failed, 
irrespective of if YOU think you know better than THEM or not, if we 
hardfail we accept the risks that come with it.


In practice, there is a prioritizing of whose wishes I prioritize on 
the receiving systems I work with. If my customer wants to receive the 
mail and the individual generating the mail is not generating that 
desire fraudulently, I don't care much about what the domain owner 
says.


I hope you have an indemnity clause in your contracts (or written 
statement from them) to legally protect you, and your professional 
indemnity insurance (or your countries version of it) is current...


I do not work for the domain owners of the world and I am not obligated 
to enforce their usage rules on their users.


Obligated no, its your network, your rules, but honouring them is the 
correct "good netizen" thing to do.


I'm sure the crime gangs and spammers reading this list greatly 
appreciate you telling them they got better chances with you then most 
:P


Obviously I take their input seriously when trying to detect fraud but 
I've seen too many cases of "-all" being used with incomplete or 
obsolete lists of "permitted" hosts to accept that they know all of the 
places their mail gets generated.


The idea of using -all is not just configuring it and forgetting it, 
it's part of the accepted risk that if you change something, you change 
your SPF statements too, if they forget, the complaints of blocked mail 
should prompt them to fix it, or if they are just flat out too damn 
lazy, then they get what they deserve.


Adherence has improved out of sight in past 5 to 10 years, and I've seen 
no problems caused by SPF, I can't remember the last time we had one.


I've also given up all hope of getting the few places that are still 
doing transparent forwarding to adopt SRS or any other mechanisms to 
avoid SPF breakage to ever change.


I guess the traffic with them is low, if it was high, blocking would 
likely get them off their buts.


--
Regards,
Noel Butler

Re: Whitelist rules should never pass on SPF fail

[Bill Cole]

On 2024-05-09 at 17:21:07 UTC-0400 (Fri, 10 May 2024 07:21:07 +1000)
Noel Butler 
is rumored to have said:

> So what? domain owners state hard fail it SHOULD be hard failed, irrespective 
> of if YOU think you know better than THEM or not, if we hardfail we accept 
> the risks that come with it.

In principle, that is fine (as a demonstration of why some principles are 
pointless and do more harm than good...)

In practice, there is a prioritizing of whose wishes I prioritize on the 
receiving systems I work with. If my customer wants to receive the mail and the 
individual generating the mail is not generating that desire fraudulently, I 
don't care much about what the domain owner says. I do not work for the domain 
owners of the world and I am not obligated to enforce their usage rules on 
their users. Obviously I take their input seriously when trying to detect fraud 
but I've seen too many cases of "-all" being used with incomplete or obsolete 
lists of "permitted" hosts to accept that they know all of the places their 
mail gets generated.

I've also given up all hope of getting the few places that are still doing 
transparent forwarding to adopt SRS or any other mechanisms to avoid SPF 
breakage to ever change. There is no ROI in trying to fix such cases 
individually but users still want their college email addresses to work decades 
after graduating and some colleges have pandered to them. So have some 
professional orgs.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Whitelist rules should never pass on SPF fail

[Noel Butler]

On 09/05/2024 22:47, Bill Cole wrote:


On 2024-05-09 at 08:37:06 UTC-0400 (Thu, 09 May 2024 14:37:06 +0200)
Benny Pedersen 
is rumored to have said:

Bill Cole skrev den 2024-05-09 14:22:

In fact, I can't think of any whitelist test that should pass if SPF 
fails.
If you operate on the theory that a SPF failure is always a sign of 
spam, you can make your SpamAssassin always trust SPF failures 
absolutely. I would not recommend that. Some people screw up their SPF 
records. Other people forward mail transparently, which reliably breaks 
SPF. SPF is broken *by design* as a spam control tool AND as a mail 
authentication tool. We knew this 20 years ago, but it remains a useful 
tool if you work with its limits rather than assuming that they do not 
exist.


spf domain owner asked for hardfails, so why not score spf_fail as 100 ? 
:)
I believe that has been covered in extreme detail and redundancy here 
and in other email-related fora MANY times over the past 20 years.


Domain owners do not KNOW all the paths their mail follows, even when 
they think that they do. Users frequently find ways to break SPF without 
doing anything wrong.


It's not often I agree with what Benny says, but this is one of them.

So what? domain owners state hard fail it SHOULD be hard failed, 
irrespective of if YOU think you know better than THEM or not, if we 
hardfail we accept the risks that come with it.


This is why SPF should always be handled separately by a milter, so a 
hard fail wont make it to spamassassin or others who think they can 
ignore a domain owners wishes.


--
Regards,
Noel Butler

Re: Whitelist rules should never pass on SPF fail

[Bill Cole]

On 2024-05-09 at 08:37:06 UTC-0400 (Thu, 09 May 2024 14:37:06 +0200)
Benny Pedersen 
is rumored to have said:


Bill Cole skrev den 2024-05-09 14:22:

In fact, I can't think of any whitelist test that should pass if SPF 
fails.


If you operate on the theory that a SPF failure is always a sign of 
spam, you can make your SpamAssassin always trust SPF failures 
absolutely. I would not recommend that. Some people screw up their 
SPF records. Other people forward mail transparently, which reliably 
breaks SPF. SPF is broken *by design* as a spam control tool AND as a 
mail authentication tool. We knew this 20 years ago, but it remains a 
useful tool if you work with its limits rather than assuming that 
they do not exist.


spf domain owner asked for hardfails, so why not score spf_fail as 100 
? :)


I believe that has been covered in extreme detail and redundancy here 
and in other email-related fora MANY times over the past 20 years.


Domain owners do not KNOW all the paths their mail follows, even when 
they think that they do. Users frequently find ways to break SPF without 
doing anything wrong.



on the other hans if spf domain owner asked for softfails it would not 
still be 100


but i still suggest to report to dnswl, if not dnswl none listed


Reasonable advice.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire

Re: Whitelist rules should never pass on SPF fail

[Benny Pedersen]

Bill Cole skrev den 2024-05-09 14:22:

In fact, I can't think of any whitelist test that should pass if SPF 
fails.


If you operate on the theory that a SPF failure is always a sign of 
spam, you can make your SpamAssassin always trust SPF failures 
absolutely. I would not recommend that. Some people screw up their SPF 
records. Other people forward mail transparently, which reliably breaks 
SPF. SPF is broken *by design* as a spam control tool AND as a mail 
authentication tool. We knew this 20 years ago, but it remains a useful 
tool if you work with its limits rather than assuming that they do not 
exist.


spf domain owner asked for hardfails, so why not score spf_fail as 100 ? 
:)


on the other hans if spf domain owner asked for softfails it would not 
still be 100


but i still suggest to report to dnswl, if not dnswl none listed

Re: Whitelist rules should never pass on SPF fail

[Bill Cole]

On 2024-05-08 at 15:53:47 UTC-0400 (Wed, 08 May 2024 16:53:47 -0300)
kurt.va1der.ca via users 
is rumored to have said:

I received a (relatively) well crafted Phishing email today.  It was 
clearly a well planned campaign.  The Spamassassin score was as 
follows:


X-Spam-Status: No, score=-0.4 required=5.0 
tests=GOOG_REDIR_NORDNS=0.001,

HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001,
NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,
SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397
autolearn=disabled version=3.4.6

DNS white-hole list checks should never ever pass if the SPF checks 
fail.


The only "white-hole" item there is RCVD_IN_DNSWL_HI, which is a 
DNS-based list where IPs which are supposedly "good" can be listed, i.e. 
it is external to SA, not something we manage. You are suggesting that 
the knowledge that an IP does not send spam should be entirely ignored 
if that IP offers a message which fails SPF, which is a solely a domain 
verification and has well-known common failure modes.


I could not disagree more. One purpose in principle for IP-wise 
welcomelisting like DNSWL is to identify known-good transparent 
forwarders who for whatever reason do not implement SRS but also do not 
forward spam.


DNS-based list IP tests are scored in the default distribution without a 
strong  basis, because they do not normally get handled by the RuleQA 
process. It has often been reported here that RCVD_IN_DNSWL_HI is too 
forgiving and that seems true to me. You may wish to reduce its positive 
power. I set it to -2 based on my local observations. YMMV.


You are free to create a local meta-rule which makes SPF_FAIL cancel out 
RCVD_IN_DNSWL_HI. You are free to make the SPF_FAIL score higher. You 
are free to use the priority and shortcircuiting features to assure that 
SPF_FAIL causes DNSWL checks to not be run. I would not expect any of 
these to have an overall positive effect on your email.


In fact, I can't think of any whitelist test that should pass if SPF 
fails.


If you operate on the theory that a SPF failure is always a sign of 
spam, you can make your SpamAssassin always trust SPF failures 
absolutely. I would not recommend that. Some people screw up their SPF 
records. Other people forward mail transparently, which reliably breaks 
SPF. SPF is broken *by design* as a spam control tool AND as a mail 
authentication tool. We knew this 20 years ago, but it remains a useful 
tool if you work with its limits rather than assuming that they do not 
exist.


I could attach a higher score to SPF_FAIL, but that would unduly 
affect cases where the sender wasn't white listed.


I fail to see how that's a problem, in a world where SPF failure 
overrides an IP-based welcome list. However, I do not understand that 
world in general, so I'm sure there's something I'm missing...


I need a way to force Spammassassin to negate the effect of one test 
on the passing of another.


A simple logical problem:

 score RULE_A 3
 score RULE_B -2

 meta  CANCEL_B_IF_A  RULE_A && RULE_B
 score CANCEL_B_IF_A  2

You can also use 'priority' directives to make rules execute in a 
defined order  and a 'shortcircuit' directive to make SA stop processing 
later rules if a specific rule hits. This will also skip any other 
'late' checks, so you have to set priorities with care to avoid 
shortcircuiting rules that you want checked. Consult the docs for 
details.




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com 
addresses)

Not Currently Available For Hire

Re: Whitelist rules should never pass on SPF fail

[Benny Pedersen]

kurt.va1der.ca via users skrev den 2024-05-08 21:53:

I received a (relatively) well crafted Phishing email today.  It was
clearly a well planned campaign.  The Spamassassin score was as
follows:

X-Spam-Status: No, score=-0.4 required=5.0
tests=GOOG_REDIR_NORDNS=0.001,
HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001,
NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,

SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397
autolearn=disabled version=3.4.6

DNS white-hole list checks should never ever pass if the SPF checks
fail.  In fact, I can't think of any whitelist test that should pass
if SPF fails.  I could attach a higher score to SPF_FAIL, but that
would unduly affect cases where the sender wasn't white listed.

I need a way to force Spammassassin to negate the effect of one test
on the passing of another.


https://www.dnswl.org/?page_id=17

you should solve URIBL_BLOCKED aswell

and lastly 3.4.6 is old now

more help ?

Re: Whitelist rules should never pass on SPF fail

[Noel Butler]

On 09/05/2024 05:57, Jarland Donnell wrote:

That's easy though at least. Set the DNSWL rule to 0. I appreciate 
their effort but it's simply not an accurate way to determine the value 
of an email in 2024. It's never been the deciding factor between 
whether or not an email was spam, in any email I've audited in the last 
decade.


This!

Trust must be earned, not assumed (or bought)

--
Regards,
Noel Butler

Re: Whitelist rules should never pass on SPF fail

[Loren Wilton]

Obviously the right way is for the master rules to be adjusted. But if you want 
a local fix, try something like this:

score   RCVD_IN_DNSWL_HI   -0.001

metaMY_RCVD_IN_DNSWL_HIRCVD_IN_DNSWL_HI && !SPF_FAIL
score   MY_RCVD_IN_DNSWL_HI-5
describeMY_RCVD_IN_DNSWL_HI    In DNS whitelist, good SPF

  - Original Message - 
  I received a (relatively) well crafted Phishing email today.  It was clearly 
a well planned campaign.  The Spamassassin score was as follows:

  X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORDNS=0.001,
  HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001,
  NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,
  SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397
  autolearn=disabled version=3.4.6

  DNS white-hole list checks should never ever pass if the SPF checks fail.  In 
fact, I can't think of any whitelist test that should pass if SPF fails.  I 
could attach a higher score to SPF_FAIL, but that would unduly affect cases 
where the sender wasn't white listed.

  I need a way to force Spammassassin to negate the effect of one test on the 
passing of another.

Re: Whitelist rules should never pass on SPF fail

[Jarland Donnell]

That’s easy though at least. Set the DNSWL rule to 0. I appreciate their effort 
but it’s simply not an accurate way to determine the value of an email in 2024. 
It’s never been the deciding factor between whether or not an email was spam, 
in any email I’ve audited in the last decade.

> On Wednesday, May 08, 2024 at 2:53 PM, kurt.va1der.ca via users 
> mailto:users@spamassassin.apache.org)> wrote:
>
> I received a (relatively) well crafted Phishing email today. It was clearly a 
> well planned campaign. The Spamassassin score was as follows:
>
>
> X-Spam-Status: No, score=-0.4 required=5.0 tests=GOOG_REDIR_NORDNS=0.001,
> HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001,
> NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,
> SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397
> autolearn=disabled version=3.4.6
>
>
> DNS white-hole list checks should never ever pass if the SPF checks fail. In 
> fact, I can't think of any whitelist test that should pass if SPF fails. I 
> could attach a higher score to SPF_FAIL, but that would unduly affect cases 
> where the sender wasn't white listed.
>
>
> I need a way to force Spammassassin to negate the effect of one test on the 
> passing of another.
>
>
>
>
>
>
>

Whitelist rules should never pass on SPF fail

[kurt.va1der.ca via users]

I received a (relatively) well crafted Phishing email today.  It was 
clearly a well planned campaign.  The Spamassassin score was as follows:


X-Spam-Status: No, score=-0.4 required=5.0 
tests=GOOG_REDIR_NORDNS=0.001,

HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001,
NORDNS_LOW_CONTRAST=0.001,RCVD_IN_DNSWL_HI=-5,RDNS_NONE=1.274,

SPF_FAIL=0.919,SPF_HELO_NONE=0.001,URIBL_BLOCKED=0.001,WIKI_IMG=2.397

autolearn=disabled version=3.4.6

DNS white-hole list checks should never ever pass if the SPF checks 
fail.  In fact, I can't think of any whitelist test that should pass if 
SPF fails.  I could attach a higher score to SPF_FAIL, but that would 
unduly affect cases where the sender wasn't white listed.


I need a way to force Spammassassin to negate the effect of one test on 
the passing of another.

Re: Weird whitelist

[natan]

Hi
Jimmy in SA like:


There might be some Spam/Phishing emails with null sender so 
spamassassin will help you block it if you configured them correctly..



header    SPAM_FROM_NO_DOMAIN    Return-Path =~ /<>/
describe  SPAM_FROM_NO_DOMAIN    spamik
score SPAM_FROM_NO_DOMAIN              2



On Mon, Apr 8, 2024 at 5:38 PM Benny Pedersen  wrote:

natan skrev den 2024-04-08 12:31:

>>>
>>> Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed
>>> BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <>
>>> -> , Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id:
>>> 6LRhEwtUmP7u, Hits: -, size: 10888, queued_as: 4VBDq06n69z1Q9q1,
>>> 358 ms
>>>
>>> I check and I not found any <> in whitelist
>  I check and nothging check whitelist in sql and nothing abou
> whitelisted sender <>
>
>> check amavis config.

read books :)

<> is bounce addresse with must not be rejected

hence its whitelisted



--

Re: Weird whitelist

[natan]

Hi
Problem solved: user in wbl sql add in amavis_recipients his domain

W dniu 8.04.2024 o 12:50, Jimmy pisze:
According to RFC 2298, the envelope sender address (SMTP MAIL FROM) of 
the Message Disposition Notification (MDN) must be null (<>). This 
specification indicates that no Delivery Status Notification (DSN) 
messages or other notifications about successful or unsuccessful 
delivery should be sent in response to an MDN.


In the context of SMTP, there are two important aspects to consider 
regarding the From and To entries:


- SMTP Commands: When issuing SMTP commands, it's possible to use "<>" 
to represent the mail server sending the response. According to the 
RFC 2298, this usage of "<>" is not intended to be blocked.


- Email Body Fields: Within the email body itself, the To, CC (Carbon 
Copy), BCC (Blind Carbon Copy), and From fields can be left blank if 
they are not relevant to the SMTP server's operation. These fields 
primarily serve the client's use. It's important to note that the 
"MAIL FROM:" command in SMTP and the "From:" field in the email 
message do not necessarily need to match, nor do the "RCPT TO:" 
command and the To field in the email message. This flexibility allows 
for different handling of sender and recipient information between the 
SMTP protocol and email content.


There might be some Spam/Phishing emails with null sender so 
spamassassin will help you block it if you configured them correctly..



On Mon, Apr 8, 2024 at 5:38 PM Benny Pedersen  wrote:

natan skrev den 2024-04-08 12:31:

>>>
>>> Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed
>>> BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <>
>>> -> , Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id:
>>> 6LRhEwtUmP7u, Hits: -, size: 10888, queued_as: 4VBDq06n69z1Q9q1,
>>> 358 ms
>>>
>>> I check and I not found any <> in whitelist
>  I check and nothging check whitelist in sql and nothing abou
> whitelisted sender <>
>
>> check amavis config.

read books :)

<> is bounce addresse with must not be rejected

hence its whitelisted



--

Re: Weird whitelist

[Jimmy]

According to RFC 2298, the envelope sender address (SMTP MAIL FROM) of the
Message Disposition Notification (MDN) must be null (<>). This
specification indicates that no Delivery Status Notification (DSN) messages
or other notifications about successful or unsuccessful delivery should be
sent in response to an MDN.

In the context of SMTP, there are two important aspects to consider
regarding the From and To entries:

- SMTP Commands: When issuing SMTP commands, it's possible to use "<>" to
represent the mail server sending the response. According to the RFC 2298,
this usage of "<>" is not intended to be blocked.

- Email Body Fields: Within the email body itself, the To, CC (Carbon
Copy), BCC (Blind Carbon Copy), and From fields can be left blank if they
are not relevant to the SMTP server's operation. These fields primarily
serve the client's use. It's important to note that the "MAIL FROM:"
command in SMTP and the "From:" field in the email message do not
necessarily need to match, nor do the "RCPT TO:" command and the To field
in the email message. This flexibility allows for different handling of
sender and recipient information between the SMTP protocol and email
content.

There might be some Spam/Phishing emails with null sender so spamassassin
will help you block it if you configured them correctly..


On Mon, Apr 8, 2024 at 5:38 PM Benny Pedersen  wrote:

> natan skrev den 2024-04-08 12:31:
>
> >>>
> >>> Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed
> >>> BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <>
> >>> -> , Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id:
> >>> 6LRhEwtUmP7u, Hits: -, size: 10888, queued_as: 4VBDq06n69z1Q9q1,
> >>> 358 ms
> >>>
> >>> I check and I not found any <> in whitelist
> >  I check and nothging check whitelist in sql and nothing abou
> > whitelisted sender <>
> >
> >> check amavis config.
>
> read books :)
>
> <> is bounce addresse with must not be rejected
>
> hence its whitelisted
>
>

Re: Weird whitelist

[natan]

W dniu 8.04.2024 o 12:38, Benny Pedersen pisze:

natan skrev den 2024-04-08 12:31:



Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed
BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <>
-> , Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id:
6LRhEwtUmP7u, Hits: -, size: 10888, queued_as: 4VBDq06n69z1Q9q1,
358 ms

I check and I not found any <> in whitelist

 I check and nothging check whitelist in sql and nothing abou
whitelisted sender <>


check amavis config.


read books :)
yes read read byt this is not from bounce. Normal bounce not have info 
in log like "wbl: whitelisted sender <>"


Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) wbl: whitelisted 
sender <>, 




<> is bounce addresse with must not be rejected

hence its whitelisted



--

Re: Weird whitelist

[Benny Pedersen]

natan skrev den 2024-04-08 12:31:



Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed
BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <>
-> , Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id:
6LRhEwtUmP7u, Hits: -, size: 10888, queued_as: 4VBDq06n69z1Q9q1,
358 ms

I check and I not found any <> in whitelist

 I check and nothging check whitelist in sql and nothing abou
whitelisted sender <>


check amavis config.


read books :)

<> is bounce addresse with must not be rejected

hence its whitelisted

Re: Weird whitelist

[natan]

W dniu 8.04.2024 o 12:26, Matus UHLAR - fantomas pisze:

On 08.04.24 12:09, natan wrote:

I use amavis+SA and In log I get "whitlisted"

...
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) wbl: 
whitelisted sender <>, 

...

Log:
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) Checking: 
6LRhEwtUmP7u [34.23.17.0] <> -> 
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) p002 1 
Content-Type: multipart/related
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) p001 1/1 
Content-Type: text/html, base64, size: 7409, SHA1 digest: 
74442afff932dbc7aa40fcd95c5445df29e8a5cc
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) check_header: 
7, Missing required header field: "Date"
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) wbl: 
whitelisted sender <>, 


this looks like whitelist at amavis level, not at spamassassin level.

Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) bounce 
unverifiable, <> -> 
Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) 6LRhEwtUmP7u 
FWD from <> -> , BODY=7BIT 250 2.0.0 from 
MTA(smtp:[86.xxx.xxx.xxx]:10027): 250 2.0.0 Ok: queued as 
4VBDq06n69z1Q9q1


Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed 
BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <> -> 
, Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id: 6LRhEwtUmP7u, 
Hits: -, size: 10888, queued_as: 4VBDq06n69z1Q9q1, 358 ms


I check and I not found any <> in whitelist


I check and nothging check whitelist in sql and nothing abou whitelisted 
sender <>

check amavis config.



--

Re: Weird whitelist

[Matus UHLAR - fantomas]

On 08.04.24 12:09, natan wrote:

I use amavis+SA and In log I get "whitlisted"

...
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) wbl: whitelisted 
sender <>, 

...

Log:
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) Checking: 
6LRhEwtUmP7u [34.23.17.0] <> -> 
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) p002 1 
Content-Type: multipart/related
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) p001 1/1 
Content-Type: text/html, base64, size: 7409, SHA1 digest: 
74442afff932dbc7aa40fcd95c5445df29e8a5cc
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) check_header: 7, 
Missing required header field: "Date"
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) wbl: whitelisted 
sender <>, 


this looks like whitelist at amavis level, not at spamassassin level.

Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) bounce 
unverifiable, <> -> 
Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) 6LRhEwtUmP7u FWD 
from <> -> , BODY=7BIT 250 2.0.0 from 
MTA(smtp:[86.xxx.xxx.xxx]:10027): 250 2.0.0 Ok: queued as 
4VBDq06n69z1Q9q1


Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed 
BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <> -> 
, Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id: 6LRhEwtUmP7u, 
Hits: -, size: 10888, queued_as: 4VBDq06n69z1Q9q1, 358 ms


I check and I not found any <> in whitelist


check amavis config. 


--
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.
Windows found: (R)emove, (E)rase, (D)elete

Weird whitelist

[natan]

Hi
I use amavis+SA and In log I get "whitlisted"

...
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) wbl: whitelisted 
sender <>, 

...

Log:
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) Checking: 
6LRhEwtUmP7u [34.23.17.0] <> -> 
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) p002 1 
Content-Type: multipart/related
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) p001 1/1 
Content-Type: text/html, base64, size: 7409, SHA1 digest: 
74442afff932dbc7aa40fcd95c5445df29e8a5cc
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) check_header: 7, 
Missing required header field: "Date"
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) wbl: whitelisted 
sender <>, 
Apr  6 01:15:08 amavis3 amavis[3887068]: (3887068-17) bounce 
unverifiable, <> -> 
Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) 6LRhEwtUmP7u FWD 
from <> -> , BODY=7BIT 250 2.0.0 from 
MTA(smtp:[86.xxx.xxx.xxx]:10027): 250 2.0.0 Ok: queued as 4VBDq06n69z1Q9q1


Apr  6 01:15:09 amavis3 amavis[3887068]: (3887068-17) Passed 
BAD-HEADER-7 {RelayedInbound}, [34.23.17.0]:38582 [34.23.17.0] <> -> 
, Queue-ID: 4VBDq04Bn7z1Q9qQ, mail_id: 6LRhEwtUmP7u, Hits: 
-, size: 10888, queued_as: 4VBDq06n69z1Q9q1, 358 ms


I check and I not found any <> in whitelist
--

Re: Order of handling whitelist/blacklist

[Benny Pedersen]

Philip Prindeville via users skrev den 2024-03-28 18:55:


My config also has:

trusted_networks 192.168.6.0/24
trusted_networks 192.168.8.0/24
trusted_networks 127.0.0.1/32

So I don't think that's the problem.


rfc 1918 is imho hardcoded into spamassassin

if its this, make a bugzilla about it, the above range is one single 
192.168.0.0/16 127.0.0.0/8


What are some steps to troubleshoot how the white/black-listing is 
happening?


spamassassin -D -t spam-msg-file 2>&1 | less

if its there :)

Re: Order of handling whitelist/blacklist

[Philip Prindeville via users]

> On Mar 28, 2024, at 12:18 PM, Matus UHLAR - fantomas  
> wrote:
> 
>>> On 27.03.24 20:56, Philip Prindeville via users wrote:
 I have something that looks like:
 
 whitelist_from_rcvd v...@yandex.ru vger.kernel.org
 
 blacklist_from *@yandex.ru
 
 And I only ever seem to see the 2nd rule being hit, but not the first.
 
 What is the order of evaluation?  Mail::SpamAssassin::Conf doesn't say 
 that I could find.
 
 You'd think the first would happen first, since it's more specific.
 
 Or, maybe that both would happen.
> 
>>> On Mar 28, 2024, at 2:39 AM, Matus UHLAR - fantomas  
>>> wrote:
>>> they both should happen.
>>> note that the second argument must be Received: header provided by trusted 
>>> server, so that argument depends on proper TrustPath set up
>>> 
>>> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath
> 
> On 28.03.24 11:55, Philip Prindeville via users wrote:
>> My config also has:
>> 
>> trusted_networks 192.168.6.0/24
>> trusted_networks 192.168.8.0/24
>> trusted_networks 127.0.0.1/32
>> 
>> So I don't think that's the problem.
>> 
>> What are some steps to troubleshoot how the white/black-listing is happening?
> 
> can you show us the headers? Here or somewhere on pastebin?
> 


No need, but thanks.

Got my head out of my butt.  I had somehow missed that vger.kernel.org as a 
"multihomed" (or "anycast", depending on how you look at it) had ceased to 
exist as an outbound relay for the LKML's and been replaced by 
(am|ny|sv|sy).mirrors.kernel.org back around Dec 19 last year.

When I switched to:

whitelist_from_rcvd v...@yandex.ru mirrors.kernel.org

things started working again.

-Philip

Re: Order of handling whitelist/blacklist

[Philip Prindeville via users]

> On Mar 28, 2024, at 12:18 PM, Matus UHLAR - fantomas  
> wrote:
> 
>>> On 27.03.24 20:56, Philip Prindeville via users wrote:
 I have something that looks like:
 
 whitelist_from_rcvd v...@yandex.ru vger.kernel.org
 
 blacklist_from *@yandex.ru
 
 And I only ever seem to see the 2nd rule being hit, but not the first.
 
 What is the order of evaluation?  Mail::SpamAssassin::Conf doesn't say 
 that I could find.
 
 You'd think the first would happen first, since it's more specific.
 
 Or, maybe that both would happen.
> 
>>> On Mar 28, 2024, at 2:39 AM, Matus UHLAR - fantomas  
>>> wrote:
>>> they both should happen.
>>> note that the second argument must be Received: header provided by trusted 
>>> server, so that argument depends on proper TrustPath set up
>>> 
>>> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath
> 
> On 28.03.24 11:55, Philip Prindeville via users wrote:
>> My config also has:
>> 
>> trusted_networks 192.168.6.0/24
>> trusted_networks 192.168.8.0/24
>> trusted_networks 127.0.0.1/32
>> 
>> So I don't think that's the problem.
>> 
>> What are some steps to troubleshoot how the white/black-listing is happening?
> 
> can you show us the headers? Here or somewhere on pastebin?
> 


No need, but thanks.

Got my head out of my butt.  I had somehow missed that vger.kernel.org as a 
"multihomed" (or "anycast", depending on how you look at it) had ceased to 
exist as an outbound relay for the LKML's and been replaced by 
(am|ny|sv|sy).mirrors.kernel.org back around Dec 19 last year.

When I switched to:

whitelist_from_rcvd v...@yandex.ru mirrors.kernel.org

things started working again.

-Philip

Re: Order of handling whitelist/blacklist

[David B Funk]

On Thu, 28 Mar 2024, Philip Prindeville via users wrote:





On Mar 28, 2024, at 2:39 AM, Matus UHLAR - fantomas  wrote:

On 27.03.24 20:56, Philip Prindeville via users wrote:

I have something that looks like:

whitelist_from_rcvd v...@yandex.ru vger.kernel.org

blacklist_from *@yandex.ru

And I only ever seem to see the 2nd rule being hit, but not the first.



[snip..]



My config also has:

trusted_networks 192.168.6.0/24
trusted_networks 192.168.8.0/24
trusted_networks 127.0.0.1/32

So I don't think that's the problem.

What are some steps to troubleshoot how the white/black-listing is happening?


whitelist_from_rcvd requires SA to 'see' the envelope from address.
Depending on how you have SA glued into your MTA that may not be happening and 
may require particular configurations.


Try creating an entry for a known good address and see if it fires.

If that source properly DKIM or SPF signs its messages it may be easier to use 
'whitelist_auth' instead of whitelist_from_rcvd.


It's also less maintenance headache as whitelist_from_rcvd must have the proper 
DNS names of their exit-point SMTP servers and in Cloud land that can change 
with out notice.


--
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: Order of handling whitelist/blacklist

[Matus UHLAR - fantomas]

On 27.03.24 20:56, Philip Prindeville via users wrote:

I have something that looks like:

whitelist_from_rcvd v...@yandex.ru vger.kernel.org

blacklist_from *@yandex.ru

And I only ever seem to see the 2nd rule being hit, but not the first.

What is the order of evaluation?  Mail::SpamAssassin::Conf doesn't say that I 
could find.

You'd think the first would happen first, since it's more specific.

Or, maybe that both would happen.



On Mar 28, 2024, at 2:39 AM, Matus UHLAR - fantomas  wrote:
they both should happen.
note that the second argument must be Received: header provided by trusted 
server, so that argument depends on proper TrustPath set up

https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath


On 28.03.24 11:55, Philip Prindeville via users wrote:

My config also has:

trusted_networks 192.168.6.0/24
trusted_networks 192.168.8.0/24
trusted_networks 127.0.0.1/32

So I don't think that's the problem.

What are some steps to troubleshoot how the white/black-listing is happening?


can you show us the headers? Here or somewhere on pastebin?

--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease

Re: Order of handling whitelist/blacklist

[Philip Prindeville via users]

> On Mar 28, 2024, at 2:39 AM, Matus UHLAR - fantomas  wrote:
> 
> On 27.03.24 20:56, Philip Prindeville via users wrote:
>> I have something that looks like:
>> 
>> whitelist_from_rcvd v...@yandex.ru vger.kernel.org
>> 
>> blacklist_from *@yandex.ru
>> 
>> And I only ever seem to see the 2nd rule being hit, but not the first.
>> 
>> What is the order of evaluation?  Mail::SpamAssassin::Conf doesn't say that 
>> I could find.
>> 
>> You'd think the first would happen first, since it's more specific.
>> 
>> Or, maybe that both would happen.
> 
> they both should happen.
> note that the second argument must be Received: header provided by trusted 
> server, so that argument depends on proper TrustPath set up
> 
> https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath
> -- 
> 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.
>   One OS to rule them all, One OS to find them,
> One OS to bring them all and into darkness bind them

My config also has:

trusted_networks 192.168.6.0/24
trusted_networks 192.168.8.0/24
trusted_networks 127.0.0.1/32

So I don't think that's the problem.

What are some steps to troubleshoot how the white/black-listing is happening?

Thanks

Re: Order of handling whitelist/blacklist

[Matus UHLAR - fantomas]

On 27.03.24 20:56, Philip Prindeville via users wrote:

I have something that looks like:

whitelist_from_rcvd v...@yandex.ru vger.kernel.org

blacklist_from  *@yandex.ru

And I only ever seem to see the 2nd rule being hit, but not the first.

What is the order of evaluation?  Mail::SpamAssassin::Conf doesn't say that I 
could find.

You'd think the first would happen first, since it's more specific.

Or, maybe that both would happen.


they both should happen.
note that the second argument must be Received: header provided by trusted 
server, so that argument depends on proper TrustPath set up


https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustPath
 
--

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.
   One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them

Order of handling whitelist/blacklist

[Philip Prindeville via users]

Hi.

I have something that looks like:

whitelist_from_rcvd v...@yandex.ru vger.kernel.org

blacklist_from  *@yandex.ru

And I only ever seem to see the 2nd rule being hit, but not the first.

What is the order of evaluation?  Mail::SpamAssassin::Conf doesn't say that I 
could find.

You'd think the first would happen first, since it's more specific.

Or, maybe that both would happen.

Re: Whitelist or add negative values for score

[Matus UHLAR - fantomas]

On 23.12.22 21:24, Joey J wrote:

This is the best I can grab header wise, Names/IP's have changed here to
protect privacy.
Know the following:
The senders real server (1.2.3.4), (1.2.3.4 is the SPF match) sends the
mail to the gateway, and the gateway blocked it as shown.
Yes, legit going to paypal.



Dec 19 19:39:42 mgw postfix/smtpd[1070732]: 1270980A01: 
client=Sender.MailServer.com[1.2.3.4]
Dec 19 19:39:42 mgw postfix/cleanup[1070437]: 1270980A01: 
message-id=
Dec 19 19:39:42 mgw postfix/qmgr[5368]: 1270980A01: from=, 
size=673334, nrcpt=1 (queue active)
Dec 19 19:39:42 mgw postfix/smtpd[1070732]: disconnect from 
Sender.MailServer.com[1.2.3.4] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 
commands=7
Dec 19 19:39:42 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: new mail 
message-id=#012
Dec 19 19:39:42 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: virus 
detected: Heuristics.Phishing.Email.SpoofedDomain (clamav)
Dec 19 19:39:47 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: SA score=3/5 
time=4.186 bayes=0.00 autolearn=no autolearn_force=no 
hits=ClamAVHeuristics(3),AWL(-0.969),BAYES_00(-1.9),BIGNUM_EMAILS_MANY(2.999),DKIM_INVALID(0.1),DKIM_SIGNED(0.1),HTML_FONT_LOW_CONTRAST(0.001),HTML_MESSAGE(0.001),KAM_DMARC_STATUS(0.01),SPF_HELO_NONE(0.001),SPF_PASS(-0.001),T_FILL_THIS_FORM_SHORT(0.01),URIBL_BLOCKED(0.001)


sender address is sen...@customer.com and SPF passed (SPF_PASS), so:

welcomelist_auth sen...@customer.com 
or

welcomelist_from_spf sen...@customer.com

should both allow this sender.
I assume the sen...@customer.com is also in the From: address.

welcomelist_from_dkim sen...@customer.com
will NOT work, because there's no valid DKIM signature.



On 21.12.22 15:48, Joey J wrote:
>Thank you for pointing me in the better direction.
>Since not many people are typing these types of email , I could do the one
>off rule and it would be manageable.
>But in better seeing the welcomelist_from_spf option, I think this will be
>my first try.


On Thu, Dec 22, 2022 at 2:24 AM Matus UHLAR - fantomas  
wrote:
welcomelist_auth does the same as welcomelist_from_spf and 
welcomelist_from_dkim both.


Note that SPF is related to envelope from address and if it's different 
from header From:, it won't help you much.


You haven't provided example of mail (headers) we are talking about.
Without it, we can only guess what your problem really is and what the
solution should be.


>On Wed, Dec 21, 2022 at 2:39 PM Greg Troxel  wrote:
>> The other thing that should be done for j...@company.com is that
>> company.com should sign their mail with DKIM, and then you can
>>
>>   welcomelist_from_dkim *@company.com
>>
>> I find that many companies I deal with that produce semi-spammy mail
>> (most big companies :-) have DKIM signatures and I can welcomelist on
>> that, without welcomelisting forgeries.
>>
>> You can of course use _rcvd for the IP address.  DKIM is just nicer if
>> you can get them to do it.


--
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.
   One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them

Re: Whitelist or add negative values for score

[Joey J]

Hello All,

This is the best I can grab header wise, Names/IP's have changed here to
protect privacy.
Know the following:
The senders real server (1.2.3.4), (1.2.3.4 is the SPF match) sends the
mail to the gateway, and the gateway blocked it as shown.
Yes, legit going to paypal.

Based on your response, will assist in making the best choice.

Thanks everyone!


Dec 19 19:39:42 mgw postfix/smtpd[1070732]: connect from
Sender.MailServer.com[1.2.3.4]
Dec 19 19:39:42 mgw postfix/smtpd[1070732]: Anonymous TLS connection
established from Sender.MailServer.com[1.2.3.4]: TLSv1.2 with cipher
ECDHE-RSA-AES256-SHA384 (256/256 bits)
Dec 19 19:39:42 mgw postfix/smtpd[1070732]: 1270980A01: client=
Sender.MailServer.com[1.2.3.4]
Dec 19 19:39:42 mgw postfix/cleanup[1070437]: 1270980A01: message-id=<
mn0pr22mb3689503197a395d549ee6d0daa...@mn0pr22mb3689.namprd22.prod.outlook.com
>
Dec 19 19:39:42 mgw postfix/qmgr[5368]: 1270980A01:
from=, size=673334, nrcpt=1 (queue active)
Dec 19 19:39:42 mgw postfix/smtpd[1070732]: disconnect from
Sender.MailServer.com[1.2.3.4] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1
quit=1 commands=7
Dec 19 19:39:42 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: new mail
message-id=<
mn0pr22mb3689503197a395d549ee6d0daa...@mn0pr22mb3689.namprd22.prod.outlook.com
>#012
Dec 19 19:39:42 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: virus
detected: Heuristics.Phishing.Email.SpoofedDomain (clamav)
Dec 19 19:39:47 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: SA
score=3/5 time=4.186 bayes=0.00 autolearn=no autolearn_force=no
hits=ClamAVHeuristics(3),AWL(-0.969),BAYES_00(-1.9),BIGNUM_EMAILS_MANY(2.999),DKIM_INVALID(0.1),DKIM_SIGNED(0.1),HTML_FONT_LOW_CONTRAST(0.001),HTML_MESSAGE(0.001),KAM_DMARC_STATUS(0.01),SPF_HELO_NONE(0.001),SPF_PASS(-0.001),T_FILL_THIS_FORM_SHORT(0.01),URIBL_BLOCKED(0.001)
Dec 19 19:39:47 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: notify
 (rule: Block outgoing Spam, 342C580C8D)
Dec 19 19:39:47 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D: block
mail to  (rule: Block outgoing Spam)
Dec 19 19:39:47 mgw pmg-smtp-filter[1070564]: A760963A1044E2E16D:
processing time: 5.04 seconds (4.186, 0.664, 0)
Dec 19 19:39:47 mgw postfix/lmtp[1070520]: 1270980A01: to=<
recipi...@paypal.com>, relay=127.0.0.1[127.0.0.1]:10023, delay=5.2,
delays=0.06/0/0.05/5.1, dsn=2.7.0, status=sent (250 2.7.0 BLOCKED
(A760963A1044E2E16D))
Dec 19 19:39:47 mgw postfix/qmgr[5368]: 1270980A01: removed




On Thu, Dec 22, 2022 at 2:24 AM Matus UHLAR - fantomas 
wrote:

> On 21.12.22 15:48, Joey J wrote:
> >Thank you for pointing me in the better direction.
> >Since not many people are typing these types of email , I could do the one
> >off rule and it would be manageable.
> >But in better seeing the welcomelist_from_spf option, I think this will be
> >my first try.
>
> welcomelist_auth does the same as welcomelist_from_spf and
> welcomelist_from_dkim
> both.
>
> Note that SPF is related to envelope from address and if it's different
> from
> header From:, it won't help you much.
>
> You haven't provided example of mail (headers) we are talking about.
> Without it, we can only guess what your problem really is and what the
> solution should be.
>
>
> >On Wed, Dec 21, 2022 at 2:39 PM Greg Troxel  wrote:
> >> The other thing that should be done for j...@company.com is that
> >> company.com should sign their mail with DKIM, and then you can
> >>
> >>   welcomelist_from_dkim *@company.com
> >>
> >> I find that many companies I deal with that produce semi-spammy mail
> >> (most big companies :-) have DKIM signatures and I can welcomelist on
> >> that, without welcomelisting forgeries.
> >>
> >> You can of course use _rcvd for the IP address.  DKIM is just nicer if
> >> you can get them to do it.
> --
> 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.
> 2B|!2B, that's a question!
>


-- 
Thanks!
Joey

Re: Whitelist or add negative values for score

[John Hardin]

On Wed, 21 Dec 2022, Joey J wrote:


But in better seeing the welcomelist_from_spf option, I think this will be
my first try.


If you are *really* worried about getting faked mail from that 
correspondent, you can do something like:


whitelist_from_spf  j...@company.com
blacklist_from  j...@company.com

I have a bunch of these sort of entries in my local config:

whitelist_auth  *@wellsfargo.com
blacklist_from  *@wellsfargo.com
whitelist_auth  *@*.wellsfargo.com
blacklist_from  *@*.wellsfargo.com
whitelist_auth  *@netflix.com
blacklist_from  *@netflix.com
whitelist_auth  *@*.netflix.com
blacklist_from  *@*.netflix.com

You may need to dial back the blacklist score a bit for it to work 
reliably:


score  USER_IN_BLACKLIST   85.000  # let whitelist override blacklist


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  "Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
  does quite what I want. I wish Christopher Robin was here."
   -- Peter da Silva in a.s.r
---
 3 days until Christmas

Re: Whitelist or add negative values for score

[Matus UHLAR - fantomas]

On 21.12.22 15:48, Joey J wrote:

Thank you for pointing me in the better direction.
Since not many people are typing these types of email , I could do the one
off rule and it would be manageable.
But in better seeing the welcomelist_from_spf option, I think this will be
my first try.


welcomelist_auth does the same as welcomelist_from_spf and welcomelist_from_dkim
both.

Note that SPF is related to envelope from address and if it's different from 
header From:, it won't help you much.


You haven't provided example of mail (headers) we are talking about.
Without it, we can only guess what your problem really is and what the 
solution should be.




On Wed, Dec 21, 2022 at 2:39 PM Greg Troxel  wrote:

The other thing that should be done for j...@company.com is that
company.com should sign their mail with DKIM, and then you can

  welcomelist_from_dkim *@company.com

I find that many companies I deal with that produce semi-spammy mail
(most big companies :-) have DKIM signatures and I can welcomelist on
that, without welcomelisting forgeries.

You can of course use _rcvd for the IP address.  DKIM is just nicer if
you can get them to do it.

--
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.
2B|!2B, that's a question!

Re: Whitelist or add negative values for score

[Joey J]

Kris & Greg,

Thank you for pointing me in the better direction.
Since not many people are typing these types of email , I could do the one
off rule and it would be manageable.
But in better seeing the welcomelist_from_spf option, I think this will be
my first try.

I appreciate all of your points and it makes us all better evaluate what we
are doing and consider efficiency and effectiveness.

Thanks!!

On Wed, Dec 21, 2022 at 2:39 PM Greg Troxel  wrote:

> The other thing that should be done for j...@company.com is that
> company.com should sign their mail with DKIM, and then you can
>
>   welcomelist_from_dkim *@company.com
>
> I find that many companies I deal with that produce semi-spammy mail
> (most big companies :-) have DKIM signatures and I can welcomelist on
> that, without welcomelisting forgeries.
>
> You can of course use _rcvd for the IP address.  DKIM is just nicer if
> you can get them to do it.
>


-- 
Thanks!
Joey

Re: Whitelist or add negative values for score

[Kris Deugau]

Joey J wrote:

Thanks Everyone.
Within all of the responses, I will try to reply here.
1. The legit sender will talk about big numbers because of the real 
things he is involved with so big numbers is still a valid method to 
score, just not in this case.
2. The SPF record is set to fail on no match, however this does not 
automatically say, ok it's the approved source everything is ok, let 
them spam out, SA will still score content, and simply not score for bad 
SPF.
3. The goal is to say for user j...@company.com , 
if we can confirm the source is their mail server IP, the lets add some 
negative value, lets say -2, to allow message that might be scored such 
as the above #1 because they are legit.


Unless there is something I'm missing, I'm not sure how to better 
explain it.
Yes, I can provide the full headers, but I thought the spam info was 
enough to provide the SA aspect of the scoring.


This is why I thought of the extra rule based on email address and IP 
combo, almost confirming its legit, to add ot the negative score.


If you really want to go down this road, and assign small or 
individualized scores for senders like this instead of just using 
welcomelist_from_(rcvd|dkim|spf) or welcomelist_auth, use something like 
this:


header __FROM_GOODGUY   From:addr =~ /^joe\@company\.com$/
header __RCVD_GOODGUY   X-Spam-Relays-External =~ /^\[ ip=1\.2\.3\.4 /
meta NOTSPAM_GOODGUY__FROM_GOODGUY && __RCVD_GOODGUY
describe NOTSPAM_GOODGUY Score nudge for j...@company.com
score NOTSPAM_GOODGUY   -2

Have a long read through "man Mail::SpamAssassin::Conf" to deconstruct 
those.


But that doesn't scale well to very many senders, where welcomelist_* 
seem to scale pretty well to at least low thousands of entries.  _spf 
and _dkim in particular also rely on other information published by the 
sender, so *you* don't have to keep manually updating your rules if 
their mail sending infrastructure changes.


I'd be more inclined to to some per-user score setting on the 
*recipient* account - ie, whoever is receiving these can have a line 
added to ~/.spamassassin/user_prefs (or whereever you're storing SA 
userprefs) saying "score BIGNUM_EMAILS_MANY (-1)".


I'd also see if you can narrow down exactly what 
Phishing.Email.SpoofedDomain is hitting on, IME it's all too likely to 
fire on a certain class of legitimate mail and what you've described 
sounds like a prime place for FPs.  Calling ClamAV like this either 
requires a plugin or relies on ClamAV being called earlier, and leaving 
a header for SA to check.  You'll have to do a bit more digging to find 
out how it's configured.


Locally I started with the plugin on the wiki 
(https://cwiki.apache.org/confluence/display/SPAMASSASSIN/ClamAVPlugin) 
and extended it quite a bit.  I've just posted the current production 
version at http://deepnet.cx/~kdeugau/spamtools/clamav.pm.  I have that 
particular Clam hit scored at 1.5 due to the FP potential.


-kgd

Re: Whitelist or add negative values for score

[Greg Troxel]

The other thing that should be done for j...@company.com is that
company.com should sign their mail with DKIM, and then you can

  welcomelist_from_dkim *@company.com

I find that many companies I deal with that produce semi-spammy mail
(most big companies :-) have DKIM signatures and I can welcomelist on
that, without welcomelisting forgeries.

You can of course use _rcvd for the IP address.  DKIM is just nicer if
you can get them to do it.

Re: Whitelist or add negative values for score

[Joey J]

Thanks Everyone.
Within all of the responses, I will try to reply here.
1. The legit sender will talk about big numbers because of the real things
he is involved with so big numbers is still a valid method to score, just
not in this case.
2. The SPF record is set to fail on no match, however this does not
automatically say, ok it's the approved source everything is ok, let them
spam out, SA will still score content, and simply not score for bad SPF.
3. The goal is to say for user j...@company.com, if we can confirm the
source is their mail server IP, the lets add some negative value, lets say
-2, to allow message that might be scored such as the above #1 because they
are legit.

Unless there is something I'm missing, I'm not sure how to better explain
it.
Yes, I can provide the full headers, but I thought the spam info was enough
to provide the SA aspect of the scoring.

This is why I thought of the extra rule based on email address and IP
combo, almost confirming its legit, to add ot the negative score.



On Wed, Dec 21, 2022 at 1:12 PM Bill Cole <
sausers-20150...@billmail.scconsult.com> wrote:

> On 2022-12-21 at 12:02:27 UTC-0500 (Wed, 21 Dec 2022 18:02:27 +0100)
> Matus UHLAR - fantomas 
> is rumored to have said:
> [...]>
> > On 21.12.22 11:19, Henrik K wrote:
> >> It will pass welcomelist_auth, since there is SPF_PASS, which you
> missed:
> >>
> >> SPF_PASS   -0.001 SPF: sender matches SPF record
> >
> > I understood KAM_DMARC_STATUS as failing SPF alignment.
>
>KAM_DMARC_STATUS  0.01  Test Rule for DKIM or SPF Failure with Strict
> Alignment
>
> Note that 'or' is not 'and' in that description. The message in question
> had a bad DKIM signature.
>
>
> --
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Not Currently Available For Hire
>


-- 
Thanks!
Joey

Re: Whitelist or add negative values for score

[Bill Cole]

On 2022-12-21 at 12:02:27 UTC-0500 (Wed, 21 Dec 2022 18:02:27 +0100)
Matus UHLAR - fantomas 
is rumored to have said:
[...]>
> On 21.12.22 11:19, Henrik K wrote:
>> It will pass welcomelist_auth, since there is SPF_PASS, which you missed:
>>
>> SPF_PASS   -0.001 SPF: sender matches SPF record
>
> I understood KAM_DMARC_STATUS as failing SPF alignment.

   KAM_DMARC_STATUS  0.01  Test Rule for DKIM or SPF Failure with Strict 
Alignment

Note that 'or' is not 'and' in that description. The message in question had a 
bad DKIM signature.


-- 
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Whitelist or add negative values for score

[Dominic Raferd]

On 20/12/2022 23:59, Joey J wrote:

Thanks to Bill and Matus for your responses.

Basically, the client is talking about real money transactions, 
airplanes, paypal etc, but he is a legit sender with these often 
flagged topics.
Sometimes the message goes through, but by the time you reply 2 or 3 
times, there are more of the buzz words that SA looks at based on rules.


We can't whitelist j...@company.com because of course everyone 
pretending to be him will more than likely get whitelisted and you 
know the rest.
This is why I thought if user j...@company.com from ip 1.2.3.4 
condition would allow me to add some negative score to get over the 
total flagging it as spam.


You guys would know better than I as to which would be the best 
method, I like scoring it some and going to -100.


Within the reject to the user it had the following:

Spam detection results: 3

ClamAVHeuristics 3 ClamAV heuristic test: Phishing.Email.SpoofedDomain 
(clamav)


AWL -0.969 Adjusted score from AWL reputation of From: address

BAYES_00 -1.9 Bayes spam probability is 0 to 1%

BIGNUM_EMAILS_MANY  2.999 Lots of email addresses/leads, over and over

DKIM_INVALID 0.1 DKIM or DK signature exists, but is not valid

DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid

HTML_FONT_LOW_CONTRAST 0.001 HTML font color similar or identical to 
background


HTML_MESSAGE 0.001 HTML included in message

KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict 
Alignment


SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record

SPF_PASS -0.001 SPF: sender matches SPF record

T_FILL_THIS_FORM_SHORT 0.01 Fill in a short form with personal information

URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was 
blocked.  See 
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block


My approach is like this:

describe LOCAL_WELCOMING_4 Pseudo-welcomelist (case-insensitive)
score LOCAL_WELCOMING_4 -4
header LOCAL_WELCOMING_4 From =~ /(fred\@bloggs\.com|\@jones\.com)>?\s*$/i

I have a few of these with different score reductions (4,6,8,10 etc) all 
held in /etc/spamassassin/local_welcoming.cf. If you end up with a lot 
of addresses to be 'welcomed' (as I do) you need some code to manage 
them, but the principle is simple enough: they act to reduce the score 
of any email where the 'From:' address matches the regex. They do not 
guarantee acceptance (the spam score is still calculated, only some 
amount (4 in the case above) is deducted, and they do not (in my case 
anyway) apply to virus-laden emails.

Re: Whitelist or add negative values for score

[Matus UHLAR - fantomas]

> DKIM_INVALID  0.1 DKIM or DK signature exists, but is not valid
>
> DKIM_SIGNED   0.1 Message has a DKIM or DK signature, not
> necessarily valid
>
> HTML_FONT_LOW_CONTRAST  0.001 HTML font color similar or identical to
> background
>
> HTML_MESSAGE0.001 HTML included in message
>
> KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict
> Alignment



On Wed, Dec 21, 2022 at 08:43:18AM +0100, Matus UHLAR - fantomas wrote:

this rule indicates that mail would NOT pass welcomelist_auth

If this is the mail you want then yes, you need welcomelist_from_rcvd, but
that's sender's faule.


On 21.12.22 11:19, Henrik K wrote:

It will pass welcomelist_auth, since there is SPF_PASS, which you missed:

SPF_PASS   -0.001 SPF: sender matches SPF record


I understood KAM_DMARC_STATUS as failing SPF alignment.

in such case From: is not the same as envelope From, so while SPF matches 
the envelope from, From: domain is different from the one that has to be 
listed in welcomelist_auth for it to work.


was I wrong?


We still miss example of original e-mail headers to decide better.
--
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.
LSD will make your ECS screen display 16.7 million colors

Re: Whitelist or add negative values for score

[Henrik K]

On Wed, Dec 21, 2022 at 08:43:18AM +0100, Matus UHLAR - fantomas wrote:
> > DKIM_INVALID  0.1 DKIM or DK signature exists, but is not valid
> > 
> > DKIM_SIGNED   0.1 Message has a DKIM or DK signature, not
> > necessarily valid
> > 
> > HTML_FONT_LOW_CONTRAST  0.001 HTML font color similar or identical to
> > background
> > 
> > HTML_MESSAGE0.001 HTML included in message
> > 
> > KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict
> > Alignment
> 
> this rule indicates that mail would NOT pass welcomelist_auth
> 
> If this is the mail you want then yes, you need welcomelist_from_rcvd, but
> that's sender's faule.

It will pass welcomelist_auth, since there is SPF_PASS, which you missed:

SPF_PASS   -0.001 SPF: sender matches SPF record

Re: Whitelist or add negative values for score

[Matus UHLAR - fantomas]

On 20.12.22 18:59, Joey J wrote:

Basically, the client is talking about real money transactions, airplanes,
paypal etc, but he is a legit sender with these often flagged topics.
Sometimes the message goes through, but by the time you reply 2 or 3 times,
there are more of the buzz words that SA looks at based on rules.

We can't whitelist j...@company.com because of course everyone pretending to
be him will more than likely get whitelisted and you know the rest.


You have misunderstood that welcomelist_auth means.

It means that the sender has to pass SPF or DKIM, which means that random 
people can NOT just send j...@company.com.



Within the reject to the user it had the following:
Spam detection results:  3


was this the legitimate mail? If so, your sender has multiple problems.


ClamAVHeuristics3 ClamAV heuristic test:
Phishing.Email.SpoofedDomain (clamav)


this is at least not nice, problematic I'd say.


AWL-0.969 Adjusted score from AWL reputation of From:
address

BAYES_00 -1.9 Bayes spam probability is 0 to 1%

BIGNUM_EMAILS_MANY  2.999 Lots of email addresses/leads, over and over


this is very common with spam.


DKIM_INVALID  0.1 DKIM or DK signature exists, but is not valid

DKIM_SIGNED   0.1 Message has a DKIM or DK signature, not
necessarily valid

HTML_FONT_LOW_CONTRAST  0.001 HTML font color similar or identical to
background

HTML_MESSAGE0.001 HTML included in message

KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict
Alignment


this rule indicates that mail would NOT pass welcomelist_auth 

If this is the mail you want then yes, you need welcomelist_from_rcvd, but 
that's sender's faule.



T_FILL_THIS_FORM_SHORT   0.01 Fill in a short form with personal information
URIBL_BLOCKED   0.001 ADMINISTRATOR NOTICE: The query to URIBL was
blocked.  See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block


this usually means you need to configure your own DNS server and not use 
public google/cloudflage/quad9 or your ISPs DNS servers.


--
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: Whitelist or add negative values for score

[Loren Wilton]

Personally I'd look at why BIGNUM_EMAILS_MANY is hitting and see if there is 
something the sender could do to avoid it. I'm pretty sure I've never seen that 
rule hit in any of my spam, so it must be something a bit unique.

Loren

Re: Whitelist or add negative values for score

[Joey J]

Thanks to Bill and Matus for your responses.

Basically, the client is talking about real money transactions, airplanes,
paypal etc, but he is a legit sender with these often flagged topics.
Sometimes the message goes through, but by the time you reply 2 or 3 times,
there are more of the buzz words that SA looks at based on rules.

We can't whitelist j...@company.com because of course everyone pretending to
be him will more than likely get whitelisted and you know the rest.
This is why I thought if user j...@company.com from ip 1.2.3.4 condition
would allow me to add some negative score to get over the total flagging it
as spam.

You guys would know better than I as to which would be the best method, I
like scoring it some and going to -100.

Within the reject to the user it had the following:

Spam detection results:  3

ClamAVHeuristics3 ClamAV heuristic test:
Phishing.Email.SpoofedDomain (clamav)

AWL-0.969 Adjusted score from AWL reputation of From:
address

BAYES_00 -1.9 Bayes spam probability is 0 to 1%

BIGNUM_EMAILS_MANY  2.999 Lots of email addresses/leads, over and over

DKIM_INVALID  0.1 DKIM or DK signature exists, but is not valid

DKIM_SIGNED   0.1 Message has a DKIM or DK signature, not
necessarily valid

HTML_FONT_LOW_CONTRAST  0.001 HTML font color similar or identical to
background

HTML_MESSAGE0.001 HTML included in message

KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict
Alignment

SPF_HELO_NONE   0.001 SPF: HELO does not publish an SPF Record

SPF_PASS   -0.001 SPF: sender matches SPF record

T_FILL_THIS_FORM_SHORT   0.01 Fill in a short form with personal information
URIBL_BLOCKED   0.001 ADMINISTRATOR NOTICE: The query to URIBL was
blocked.  See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block



On Tue, Dec 20, 2022 at 6:14 AM Matus UHLAR - fantomas 
wrote:

> On 19.12.22 20:05, Joey J wrote:
> >I'm trying to see if there is a "best way" to provide negative scoring for
> >a certain persons email.
> >As an example if j...@company.com is communicating with paypal or other
> real
> >banking institutions, then at times within the email chain, SA will tag it
> >as spam.
>
> do you have an example?
>
> >I want to see if there is if email is from j...@company.com AND is from IP
> >address 1.2.3.4, then lets take away 2 from the score, hopefully allowing
> >those legitimate types of messages through.
>
> there are techniques like SPF and DKIM to authenticate e-mail.
> In such case you should be able to "welcomelist_auth j...@company.com"
> without
> providing outgoing mailserver IP
>
> --
> 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.
> BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
>


-- 
Thanks!
Joey

Re: Whitelist or add negative values for score

[Matus UHLAR - fantomas]

On 19.12.22 20:05, Joey J wrote:

I'm trying to see if there is a "best way" to provide negative scoring for
a certain persons email.
As an example if j...@company.com is communicating with paypal or other real
banking institutions, then at times within the email chain, SA will tag it
as spam.


do you have an example?


I want to see if there is if email is from j...@company.com AND is from IP
address 1.2.3.4, then lets take away 2 from the score, hopefully allowing
those legitimate types of messages through.


there are techniques like SPF and DKIM to authenticate e-mail.
In such case you should be able to "welcomelist_auth j...@company.com" without 
providing outgoing mailserver IP


--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease

Re: Whitelist or add negative values for score

[Bill Cole]

On 2022-12-19 at 21:43:08 UTC-0500 (Mon, 19 Dec 2022 21:43:08 -0500)
Joey J 
is rumored to have said:


Thanks,
So welcomelist_from_rcvd j...@company.com [1.2.3.4]
Is saying if it's received from j...@company.com and the IP 
combination?

And then simply score it
 welcomelist_from_rcvd score -2
I will try that thank you!


No, there is no score line for a 'welcomelist_from_rcvd' directive.

The syntax for all of the welcomelist/blocklist directives is documented 
in Mail::SpamAssassin::Conf. You can see that with:


 perldoc Mail::SpamAssassin::Conf

In previous versions, these directives all used 'whitelist' and 
'blacklist' so if you are not running 3.4.6 or 4.0.0 those names will be 
in the docs.


The scores for the various wl/bl settings are controlled by a set of 
rules distributed and described in rules/60_welcomelist.cf. As Greg 
indicated, welcomelist_from_rcvd causes a hit on USER_IN_WELCOMELIST, 
which has a default score of -100. You can change that locally in your 
local.cf file, but it will change for ALL addresses you've used with 
welcomelist_from_rcvd or (not recommended) welcomelist_from. You can 
also use def_welcomelist_from_rcvd, which is used for the addresses in 
the "default" welcomelist which is part of the rules distribution. That 
is scored via USER_IN_DEF_WELCOMELIST, set at -15 in the distribution.


A better tool for this would be welcomelist_from_auth, which you can use 
if the sender's SPF authorizes the IP you see the mail from or if their 
mail is signed with DKIM.


The BEST solution would be to figure out specifically why the mail is 
sometimes being tagged as spam, and fix that.





On Mon, Dec 19, 2022 at 8:39 PM Greg Troxel  wrote:



Joey J  writes:

I'm trying to see if there is a "best way" to provide negative 
scoring

for

a certain persons email.


That's easy.  There are many ways, but not best way.

As an example if j...@company.com is communicating with paypal or 
other

real
banking institutions, then at times within the email chain, SA will 
tag

it

as spam.


It's really not clear what your issue is.

I want to see if there is if email is from j...@company.com AND is 
from

IP
address 1.2.3.4, then lets take away 2 from the score, hopefully 
allowing

those legitimate types of messages through.
I couldn't find an example on how to accomplish this dual criteria 
check.

Any assistance is apreciated.


welcomelist_from_rcvd   j...@company.com [1.2.3.4]

should work, but -100.  It would be nice if welcomelist_* could take 
a

score, but it you are sure you want *your* SA to not mark it as spam,
-100 is the way to spell that.




--
Thanks!
Joey



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: Whitelist or add negative values for score

[Joey J]

Actually, what would be the format, in respect to header for that rule?
so
header welcomelist_from_rcvd   j...@company.com [1.2.3.4]

On Mon, Dec 19, 2022 at 8:39 PM Greg Troxel  wrote:

>
> Joey J  writes:
>
> > I'm trying to see if there is a "best way" to provide negative scoring
> for
> > a certain persons email.
>
> That's easy.  There are many ways, but not best way.
>
> > As an example if j...@company.com is communicating with paypal or other
> real
> > banking institutions, then at times within the email chain, SA will tag
> it
> > as spam.
>
> It's really not clear what your issue is.
>
> > I want to see if there is if email is from j...@company.com AND is from
> IP
> > address 1.2.3.4, then lets take away 2 from the score, hopefully allowing
> > those legitimate types of messages through.
> > I couldn't find an example on how to accomplish this dual criteria check.
> > Any assistance is apreciated.
>
> welcomelist_from_rcvd   j...@company.com [1.2.3.4]
>
> should work, but -100.  It would be nice if welcomelist_* could take a
> score, but it you are sure you want *your* SA to not mark it as spam,
> -100 is the way to spell that.
>


-- 
Thanks!
Joey

Re: Whitelist or add negative values for score

[Joey J]

Thanks,
So welcomelist_from_rcvd j...@company.com [1.2.3.4]
Is saying if it's received from j...@company.com and the IP combination?
And then simply score it
 welcomelist_from_rcvd score -2
I will try that thank you!

On Mon, Dec 19, 2022 at 8:39 PM Greg Troxel  wrote:

>
> Joey J  writes:
>
> > I'm trying to see if there is a "best way" to provide negative scoring
> for
> > a certain persons email.
>
> That's easy.  There are many ways, but not best way.
>
> > As an example if j...@company.com is communicating with paypal or other
> real
> > banking institutions, then at times within the email chain, SA will tag
> it
> > as spam.
>
> It's really not clear what your issue is.
>
> > I want to see if there is if email is from j...@company.com AND is from
> IP
> > address 1.2.3.4, then lets take away 2 from the score, hopefully allowing
> > those legitimate types of messages through.
> > I couldn't find an example on how to accomplish this dual criteria check.
> > Any assistance is apreciated.
>
> welcomelist_from_rcvd   j...@company.com [1.2.3.4]
>
> should work, but -100.  It would be nice if welcomelist_* could take a
> score, but it you are sure you want *your* SA to not mark it as spam,
> -100 is the way to spell that.
>


-- 
Thanks!
Joey

Re: Whitelist or add negative values for score

[Greg Troxel]

Joey J  writes:

> I'm trying to see if there is a "best way" to provide negative scoring for
> a certain persons email.

That's easy.  There are many ways, but not best way.

> As an example if j...@company.com is communicating with paypal or other real
> banking institutions, then at times within the email chain, SA will tag it
> as spam.

It's really not clear what your issue is.

> I want to see if there is if email is from j...@company.com AND is from IP
> address 1.2.3.4, then lets take away 2 from the score, hopefully allowing
> those legitimate types of messages through.
> I couldn't find an example on how to accomplish this dual criteria check.
> Any assistance is apreciated.

welcomelist_from_rcvd   j...@company.com[1.2.3.4]

should work, but -100.  It would be nice if welcomelist_* could take a
score, but it you are sure you want *your* SA to not mark it as spam,
-100 is the way to spell that.


signature.asc
Description: PGP signature

Whitelist or add negative values for score

[Joey J]

Hello All,

I'm trying to see if there is a "best way" to provide negative scoring for
a certain persons email.
As an example if j...@company.com is communicating with paypal or other real
banking institutions, then at times within the email chain, SA will tag it
as spam.

I want to see if there is if email is from j...@company.com AND is from IP
address 1.2.3.4, then lets take away 2 from the score, hopefully allowing
those legitimate types of messages through.
I couldn't find an example on how to accomplish this dual criteria check.
Any assistance is apreciated.

-- 
Thanks!
Joey

Re: Txrep, add-addr-to-whitelist

[Matija Nalis]

On Sun, Dec 19, 2021 at 12:18:15AM +1030, Peter wrote:
> Today I got my life back.
> 
> Decided to ditch TXrep and go back to AWL. It might not be as clever,
> but at least it works!
> 
> The inability to do working manual changes to scores meant wasting a lot of
> time having to add addresses to my whitelist file even for addresses that
> might not ever send another email in future.
> 
> Relief...

Probably a good choice, as TxRep is currently quite broken in several
regards, see for example:

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7943

and a list of tickets in:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7173

-- 
Opinions above are GNU-copylefted.

Re: Txrep, add-addr-to-whitelist

[Peter]

Today I got my life back.

Decided to ditch TXrep and go back to AWL. It might not be as clever,
but at least it works!

The inability to do working manual changes to scores meant wasting a lot of
time having to add addresses to my whitelist file even for addresses that
might not ever send another email in future.

Relief...


*** REPLY SEPARATOR  ***

On 17/12/2021 at 1:16 AM Peter wrote:

>I just want the command to work as advertised.  It worked for AWL on my
>older system, made life a lot easier.
>
>
>*** REPLY SEPARATOR  ***
>
>On 16/12/2021 at 9:36 AM Greg Troxel wrote:
>
>>"Peter"  writes:
>>
>>> New to TXrep, the manual says the add-addr-to-whitelist command should
>>add
>>> -100, but for me it doesn't do anything - nor does
>add-addr-to-blacklist.
>>>
>>> It comes back with SpamAssassin TxRep: 1  with either the white or
>>> blacklist.
>>>
>>> While the server is new, I want to be able to adjust a senders score,
>but
>>> don't want to make new rules which will be there forever.
>>>
>>> Am I missing something?
>>
>>I have also struggled with understanding what's going on, and tried to
>>run some scripts to look at the database.
>>
>>If what you want is to preload a good reputation that will then be
>>subject to adjustment, you probably want to write a program to adjust
>>the database and say put in fake data that the average score is -5 over
>>10 messages, and then let it go.
>>
>>Beware though that txrep is per sender, per sender/addr pair, and other
>>things (I forget the details), and so you may need to put in more fake
>>data than you are willing to put up with.
>>
>>If you are putting in -100 and it stays, I don't see why that should be
>>about txrep rather than just fixed huge scores for addresses.
>>
>>I think what SA needs is a welcomelist command that takes a score, or
>>maybe just a welcomelist_mild that gives -5.  I'm uncomfortable putting
>>tons of addresses in welcomelist without dkim or rcvd, but -5 might be
>>ok, enough to keep ham out of my purgatory folders (>1 < 5) while also
>>keeping any forged spam out of inbox (<1).

Re: Txrep, add-addr-to-whitelist

[Matus UHLAR - fantomas]

On Thursday 16 December 2021 at 21:43:04, Peter wrote:

Thanks, I hadn't thought about that.

I am curious though, I normall hit Reply rather than Reply to All, and with
your email Reply just uses your own address,


that's because Anthony doesn't set Reply-To: and neither does this mailing
list (changing reply-to often breaks DKIM signatures).

You (Peter) on the other side set Reply-To: to your own address which is
rarely useful if it's the same as From:

and in this case can even cause troubles. You should only use it for list
mail if you explicitly want replies back to you, not to the list

On 16.12.21 22:14, Antony Stone wrote:

That, I find strange.

For me, selecting my own reply on the list, and then clicking on Reply, gives
me "users@spamassassin.apache.org"


apparently your mail klient (kmail) either does know its own address and
doesn't try to send replies to yourself, or explicitly uses List-Reply by
default for mail from mailing lists.

looks like Peter used discontinued Courier:
https://www.rosecitysoftware.com/courier/


I need to hit Reply to All to get it on the list.


In my opinion, Reply-to-all on a mailing list is usually a bad idea.


unfortunately, not many mail clients support mailing lists.
Thunderbird does, mutt does, kmail does.


I can only suggest that this is one of the many ways in which MS Outlook is a
disappointing mail client.


I agree much, although this it not Peter's mail client.


just my 1 PHP (1 phipiline peso = $.02)
--
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.
It's now safe to throw off your computer.

Re: Txrep, add-addr-to-whitelist

[Antony Stone]

On Thursday 16 December 2021 at 21:43:04, Peter wrote:

> Thanks, I hadn't thought about that.
> 
> I am curious though, I normall hit Reply rather than Reply to All, and with
> your email Reply just uses your own address,

That, I find strange.

For me, selecting my own reply on the list, and then clicking on Reply, gives 
me "users@spamassassin.apache.org"

> I need to hit Reply to All to get it on the list.

In my opinion, Reply-to-all on a mailing list is usually a bad idea.

Anyone who has sent a message to the list is subscribed to the list, so if you 
reply to the list (only), they will see your reply.  They do not need their 
own copy.

For example, see my sig below (and on every other posting I have made to this 
this and every other list) "Please reply to the list, and please don't CC me"

> Is that what has been happening with mine, and why does it happen with
> replies to your posts?

I don't know, but take a look at headers on my reply:
https://mail-archives.apache.org/mod_mbox/spamassassin-
users/202112.mbox/raw/<202112162128.27630.antony.st...@spamassassin.open.source.it>

Nowhere there does it say "reply to my personal address", therefore I would 
expect your mail client simply to reply to the list.

However, this is not answering the original point, which is that your mail 
client *is* inserting a Reply-To header, therefore some people reply to you 
alone and not to the list:

https://mail-archives.apache.org/mod_mbox/spamassassin-
users/202112.mbox/raw/<202112170116100961.03849...@nx33.ace.net.au>

> Is this post better?

No, because it was sent both to the list and to me personally.  Quite 
redundant.


I can only suggest that this is one of the many ways in which MS Outlook is a 
disappointing mail client.

I cannot help you to fix that, beause I have never used it.


Antony.

-- 
"I find the whole business of religion profoundly interesting.  But it does 
mystify me that otherwise intelligent people take it seriously."

 - Douglas Adams

   Please reply to the list;
 please *don't* CC me.

Re: Txrep, add-addr-to-whitelist

[Peter]

Thanks, I hadn't thought about that.   

I am curious though, I normall hit Reply rather than Reply to All, and with
your email Reply just uses your own address, I need to hit Reply to All to
get it on the list.   Is that what has been happening with mine, and why
does it happen with replies to your posts?

Is this post better?


*** REPLY SEPARATOR  ***

On 16/12/2021 at 9:28 PM Antony Stone wrote:

>On Thursday 16 December 2021 at 21:21:28, Peter wrote:
>
>> I was thinking that replies would show up here.
>
>> Perhaps I should create an account on a mail server without RBL
blocking?
>
>Either that, or (preferably) stop your email client from enforcing a
>Reply-To 
>address which is different from the mailing list.
>
>Then you will receive replies from people via the list.
>
>
>Antony.
>
>-- 
>Python is executable pseudocode.
>Perl is executable line noise.
>
>   Please reply to the
>list;
> please *don't* CC
>me.

Re: Txrep, add-addr-to-whitelist

[Antony Stone]

On Thursday 16 December 2021 at 21:21:28, Peter wrote:

> I was thinking that replies would show up here.

> Perhaps I should create an account on a mail server without RBL blocking?

Either that, or (preferably) stop your email client from enforcing a Reply-To 
address which is different from the mailing list.

Then you will receive replies from people via the list.


Antony.

-- 
Python is executable pseudocode.
Perl is executable line noise.

   Please reply to the list;
 please *don't* CC me.

Re: Txrep, add-addr-to-whitelist

[Peter]

Hi Greg,

Yeah, my blocklists are pretty extreme, normally serves me well, but I
apologize to those trying to help.   I was thinking that replies would show
up here.

I have just cleared 71.19.144.0/20 just in case so hopefully those replies
can come in.

Perhaps I should create an account on a mail server without RBL blocking?



*** REPLY SEPARATOR  ***

On 16/12/2021 at 10:01 AM Greg Troxel wrote:

>Hey Peter: Your mailserver appears to be a bit aggressive and is
>blocking mail from people on the list who are replying to you:
>
>  : host acemail1.ace.net.au[150.101.236.36] said: 553
>5.3.0
>  Rejected 71.19.148.97 by clients-b.blocked.rbl (in reply to MAIL
FROM
>  command)
>
>multirbl.valli.org shows no issues, and I'm even in DNSWL_MED.

Re: Txrep, add-addr-to-whitelist

[Greg Troxel]

Hey Peter: Your mailserver appears to be a bit aggressive and is
blocking mail from people on the list who are replying to you:

  : host acemail1.ace.net.au[150.101.236.36] said: 553 5.3.0
  Rejected 71.19.148.97 by clients-b.blocked.rbl (in reply to MAIL FROM
  command)

multirbl.valli.org shows no issues, and I'm even in DNSWL_MED.



signature.asc
Description: PGP signature

Re: Txrep, add-addr-to-whitelist

[Peter]

I just want the command to work as advertised.  It worked for AWL on my
older system, made life a lot easier.


*** REPLY SEPARATOR  ***

On 16/12/2021 at 9:36 AM Greg Troxel wrote:

>"Peter"  writes:
>
>> New to TXrep, the manual says the add-addr-to-whitelist command should
>add
>> -100, but for me it doesn't do anything - nor does
add-addr-to-blacklist.
>>
>> It comes back with SpamAssassin TxRep: 1  with either the white or
>> blacklist.
>>
>> While the server is new, I want to be able to adjust a senders score,
but
>> don't want to make new rules which will be there forever.
>>
>> Am I missing something?
>
>I have also struggled with understanding what's going on, and tried to
>run some scripts to look at the database.
>
>If what you want is to preload a good reputation that will then be
>subject to adjustment, you probably want to write a program to adjust
>the database and say put in fake data that the average score is -5 over
>10 messages, and then let it go.
>
>Beware though that txrep is per sender, per sender/addr pair, and other
>things (I forget the details), and so you may need to put in more fake
>data than you are willing to put up with.
>
>If you are putting in -100 and it stays, I don't see why that should be
>about txrep rather than just fixed huge scores for addresses.
>
>I think what SA needs is a welcomelist command that takes a score, or
>maybe just a welcomelist_mild that gives -5.  I'm uncomfortable putting
>tons of addresses in welcomelist without dkim or rcvd, but -5 might be
>ok, enough to keep ham out of my purgatory folders (>1 < 5) while also
>keeping any forged spam out of inbox (<1).

Re: Txrep, add-addr-to-whitelist

[Greg Troxel]

"Peter"  writes:

> New to TXrep, the manual says the add-addr-to-whitelist command should add
> -100, but for me it doesn't do anything - nor does add-addr-to-blacklist.
>
> It comes back with SpamAssassin TxRep: 1  with either the white or
> blacklist.
>
> While the server is new, I want to be able to adjust a senders score, but
> don't want to make new rules which will be there forever.
>
> Am I missing something?

I have also struggled with understanding what's going on, and tried to
run some scripts to look at the database.

If what you want is to preload a good reputation that will then be
subject to adjustment, you probably want to write a program to adjust
the database and say put in fake data that the average score is -5 over
10 messages, and then let it go.

Beware though that txrep is per sender, per sender/addr pair, and other
things (I forget the details), and so you may need to put in more fake
data than you are willing to put up with.

If you are putting in -100 and it stays, I don't see why that should be
about txrep rather than just fixed huge scores for addresses.

I think what SA needs is a welcomelist command that takes a score, or
maybe just a welcomelist_mild that gives -5.  I'm uncomfortable putting
tons of addresses in welcomelist without dkim or rcvd, but -5 might be
ok, enough to keep ham out of my purgatory folders (>1 < 5) while also
keeping any forged spam out of inbox (<1).


signature.asc
Description: PGP signature

Txrep, add-addr-to-whitelist

[Peter]

Hi,

New to TXrep, the manual says the add-addr-to-whitelist command should add
-100, but for me it doesn't do anything - nor does add-addr-to-blacklist.

It comes back with SpamAssassin TxRep: 1  with either the white or
blacklist.

While the server is new, I want to be able to adjust a senders score, but
don't want to make new rules which will be there forever.

Am I missing something?

Cheers.

Re: the pending whitelist* -> welcomelist* change

[jdow]

On 20201017 10:58:13, RW wrote:

On Fri, 16 Oct 2020 23:18:16 -0400
Bill Cole wrote:


On 16 Oct 2020, at 21:06, Noel Butler wrote:


perhaps, the rules above should be defined only for version >=4
and versions <4 should have the original rules.

The rule name change is an artifact of how the rules are
version-controlled. We have exactly one version of the rules and it
resides in the trunk of the Subversion repository.

And that one version of rules has separate definitions for SA versions
that support "feature_blocklist_welcomelist" and those that don't.

There's no excuse for providing confusing information.



What does NOT work is to conflate the change in rule names with a
change in configuration directive names. They are different things.

That's not at all clear from the "describe" text displayed for 3.*. The
OP assumed it was time to switch configuration and that's perfectly
reasonable IMO.


It would be wonderful if I could simply do something like "define whitelist_from 
as welcomelist_from" and admit I am a racist as far as idiots whose opinions 
about me are beneath contempt are concerned. This whole thing is falling apart 
about the way I thought it would with this kind of fundamental political 
correctness minded change.


{+_+}

Re: the pending whitelist* -> welcomelist* change

[RW]

On Fri, 16 Oct 2020 23:18:16 -0400
Bill Cole wrote:

> On 16 Oct 2020, at 21:06, Noel Butler wrote:
> 
> > perhaps, the rules above should be defined only for version >=4
> > and versions <4 should have the original rules.  
> 
> The rule name change is an artifact of how the rules are 
> version-controlled. We have exactly one version of the rules and it 
> resides in the trunk of the Subversion repository.

And that one version of rules has separate definitions for SA versions
that support "feature_blocklist_welcomelist" and those that don't. 

There's no excuse for providing confusing information.


> What does NOT work is to conflate the change in rule names with a
> change in configuration directive names. They are different things.

That's not at all clear from the "describe" text displayed for 3.*. The
OP assumed it was time to switch configuration and that's perfectly
reasonable IMO. 

Re: the pending whitelist* -> welcomelist* change

[Kevin A. McGrail]

That sums it up well for now, yes.  4.0 will even let you still use the
same config options so there is a timeline for planning for the removal
of the options with 4.1 whenever that is.

On 10/17/2020 11:10 AM, Victor Sudakov wrote:
> Thanks a lot to all who replied. So, for the uninitiated like me, I just
> keep the old white* and black* in my local.cf, and put up with the
> deprecation warning in the Spam Report. Is this correct?

-- 
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171




signature.asc
Description: OpenPGP digital signature

Re: the pending whitelist* -> welcomelist* change

[Victor Sudakov]

Bill Cole wrote:
> 
> > perhaps, the rules above should be defined only for version >=4
> > and versions <4 should have the original rules.
> 
> The rule name change is an artifact of how the rules are version-controlled.
> We have exactly one version of the rules and it resides in the trunk of the
> Subversion repository. This imposes a discipline: we MUST keep the rules
> working with the latest release, with past releases to the degree possible,
> and with the next release. This also means that rules which use new features
> get exposed to everyone before the features. A terminology change across the
> codebase isn't done instantaneously so unless you're running from a 'trunk'
> checkout, you won't see the changes outside of the rules until they are all
> done, but while adapting the rules we got a few imperfect interim stages
> before the current implementation, which just works.
> 
> What does NOT work is to conflate the change in rule names with a change in
> configuration directive names. They are different things.

Thanks a lot to all who replied. So, for the uninitiated like me, I just
keep the old white* and black* in my local.cf, and put up with the
deprecation warning in the Spam Report. Is this correct?


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/


signature.asc
Description: PGP signature

Re: the pending whitelist* -> welcomelist* change

[Bill Cole]

On 16 Oct 2020, at 21:06, Noel Butler wrote:


perhaps, the rules above should be defined only for version >=4
and versions <4 should have the original rules.


The rule name change is an artifact of how the rules are 
version-controlled. We have exactly one version of the rules and it 
resides in the trunk of the Subversion repository. This imposes a 
discipline: we MUST keep the rules working with the latest release, with 
past releases to the degree possible, and with the next release. This 
also means that rules which use new features get exposed to everyone 
before the features. A terminology change across the codebase isn't done 
instantaneously so unless you're running from a 'trunk' checkout, you 
won't see the changes outside of the rules until they are all done, but 
while adapting the rules we got a few imperfect interim stages before 
the current implementation, which just works.


What does NOT work is to conflate the change in rule names with a change 
in configuration directive names. They are different things.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: the pending whitelist* -> welcomelist* change

[Noel Butler]

On 17/10/2020 00:22, Matus UHLAR - fantomas wrote:

> On 10/16/2020 5:48 AM, Victor Sudakov wrote: My SpamAssassin reports that
> 
> -0.0 USER_IN_WELCOMELISTuser is listed in 'welcomelist_from'
> -100 USER_IN_WHITELIST  DEPRECATED: See USER_IN_WELCOMELIST
> 
> However when I change "whitelist_from" to "welcomelist_from", SpamAssassin 
> complains:
> 
> $ spamassassin --lint
> Oct 16 02:46:11.739 [11288] warn: config: failed to parse line, skipping, in 
> "/etc/spamassassin/local.cf": welcomelist_from *@
> Oct 16 02:46:12.979 [11288] warn: lint: 1 issues detected, please rerun with 
> debug enabled for more information
> 
> Am I not supposed to replace whitelist with welcomelist in my configs?

On 16.10.20 09:20, Kevin A. McGrail wrote: 

> No, not until 4.0 is released.  Good question!

perhaps, the rules above should be defined only for version >=4
and versions <4 should have the original rules. 

I agree, but since Kevin is the one forcing this political crap down our
throats, he wont care and will deny all requests, just run a perl regex
over the rules to remove/replace them ;)

-- 
Regards,
Noel Butler 

This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so. If
you are not the intended recipient, please notify the sender then delete
all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.

Re: the pending whitelist* -> welcomelist* change

[Kevin A. McGrail]

On 10/16/2020 10:22 AM, Matus UHLAR - fantomas wrote:
> On 16.10.20 09:20, Kevin A. McGrail wrote:
>> No, not until 4.0 is released.  Good question!
>
> perhaps, the rules above should be defined only for version >=4
> and versions <4 should have the original rules. 

The rule just happens to have the same name as the configuration options

The old rule IS deprecated.  The new configuration option with backwards
compatibility is a 4.0 option.

Regards,

KAM

-- 
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: the pending whitelist* -> welcomelist* change

[Matus UHLAR - fantomas]

On 10/16/2020 5:48 AM, Victor Sudakov wrote:

My SpamAssassin reports that

-0.0 USER_IN_WELCOMELISTuser is listed in 'welcomelist_from'
-100 USER_IN_WHITELIST  DEPRECATED: See USER_IN_WELCOMELIST

However when I change "whitelist_from" to "welcomelist_from", SpamAssassin 
complains:

$ spamassassin --lint
Oct 16 02:46:11.739 [11288] warn: config: failed to parse line, skipping, in 
"/etc/spamassassin/local.cf": welcomelist_from *@
Oct 16 02:46:12.979 [11288] warn: lint: 1 issues detected, please rerun with 
debug enabled for more information

Am I not supposed to replace whitelist with welcomelist in my configs?


On 16.10.20 09:20, Kevin A. McGrail wrote:

No, not until 4.0 is released.  Good question!


perhaps, the rules above should be defined only for version >=4
and versions <4 should have the original rules.

--
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.
Christian Science Programming: "Let God Debug It!".

Re: the pending whitelist* -> welcomelist* change

[Kevin A. McGrail]

On 10/16/2020 5:48 AM, Victor Sudakov wrote:
> Dear Colleagues,
>
> My SpamAssassin reports that 
>
> -0.0 USER_IN_WELCOMELISTuser is listed in 'welcomelist_from'  
>
> -100 USER_IN_WHITELIST  DEPRECATED: See USER_IN_WELCOMELIST  
>
> However when I change "whitelist_from" to "welcomelist_from", SpamAssassin 
> complains:
>
> $ spamassassin --lint
> Oct 16 02:46:11.739 [11288] warn: config: failed to parse line, skipping, in 
> "/etc/spamassassin/local.cf": welcomelist_from *@
> Oct 16 02:46:12.979 [11288] warn: lint: 1 issues detected, please rerun with 
> debug enabled for more information
>
> Am I not supposed to replace whitelist with welcomelist in my configs?
No, not until 4.0 is released.  Good question!

-- 
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: the pending whitelist* -> welcomelist* change

[RW]

On Fri, 16 Oct 2020 16:48:20 +0700
Victor Sudakov wrote:

> Dear Colleagues,
> 
> My SpamAssassin reports that 
> 
> -0.0 USER_IN_WELCOMELISTuser is listed in 'welcomelist_from'
> -100 USER_IN_WHITELIST  DEPRECATED: See USER_IN_WELCOMELIST
>
> 
> However when I change "whitelist_from" to "welcomelist_from",
> SpamAssassin complains:

It looks like it's not been ported to 3.*, but we have:


if can(Mail::SpamAssassin::Conf::feature_blocklist_welcomelist)

...

else
  header USER_IN_WELCOMELISTeval:check_from_in_whitelist()
  describe USER_IN_WELCOMELIST  user is listed in 'welcomelist_from'
  tflags USER_IN_WELCOMELISTuserconf nice noautolearn
  score USER_IN_WELCOMELIST -0.01

  meta USER_IN_WHITELIST(USER_IN_WELCOMELIST)
  describe USER_IN_WHITELISTDEPRECATED: See USER_IN_WELCOMELIST 
  tflags USER_IN_WHITELIST  userconf nice noautolearn
  score USER_IN_WHITELIST   -100.0
endif

So a feature is deprecated before the alternative is implemented. A
year ago I would have followed that by 'unbelievable'.

the pending whitelist* -> welcomelist* change

[Victor Sudakov]

Dear Colleagues,

My SpamAssassin reports that 

-0.0 USER_IN_WELCOMELISTuser is listed in 'welcomelist_from'
 
-100 USER_IN_WHITELIST  DEPRECATED: See USER_IN_WELCOMELIST  

However when I change "whitelist_from" to "welcomelist_from", SpamAssassin 
complains:

$ spamassassin --lint
Oct 16 02:46:11.739 [11288] warn: config: failed to parse line, skipping, in 
"/etc/spamassassin/local.cf": welcomelist_from *@
Oct 16 02:46:12.979 [11288] warn: lint: 1 issues detected, please rerun with 
debug enabled for more information

Am I not supposed to replace whitelist with welcomelist in my configs?


-- 
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

[John Hardin]

On Mon, 3 Aug 2020, John Wilcock wrote:


On 2020-08-01 21:23, bugzilla-dae...@spamassassin.apache.org wrote:


https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826

--- Comment #58 from Kevin A. McGrail  ---
(In reply to John Hardin from comment #57) (In reply to Kevin A. McGrail from 
comment #55)

This isn't a plugin to disable features (i.e. deprecate), it's to enable them.
So name it "EnableDeprecatedTerminology.pm"

I second the objection to "RaciallyCharged.pm". Doing that is essentially
scolding anyone who enables backwards compatibility features.


The RaciallyCharged plugin doesn't enabled deprecated terminology, it 
enables the racially charged language. It's used in the rules 
specifically for this issue and the tests as well for backwards 
compatible.  It won't be suitable as a generic plugin.  The plugin 
describes exactly what the plugin does and I stand by the name.  People 
should stop using the language.




As you cannot fail to be aware if you read even a fraction of the list
messages on this topic, there is absolutely no consensus that
blacklist/whitelist etc. are racially charged terms. Some perceive them
as such, sure, but others disagree, and indeed some disagree rather
strongly. It would seem fitting to avoid a divisive name for re-enabling
the terms.

What is indisputable is that the project has chosen to deprecate the
terms, regardless of the reasons for that deprecation. It is equally
indisputable that the plugin is for backward compatibility reasons. So
how about EnableDeprecatedTerminology or
EnableBackwardCompatibilityTerminology, which would be accurate and far
less divisive names. I suppose it might be argued that another plugin
might be needed in the future for enabling terms deprecated for other
reasons. If that is a worry, then call this one
EnableDeprecatedBlackWhiteTerminology or
EnableBackCompatBlackWhiteTerminology.


Or perhaps "EnableDeprecatedTerminology_bug7826.pm" to make it more 
specific to the terminology in question. This provides us a pattern for 
future use should other terms ever need to be deprecated for some reason.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  If asking Hillary to disarm is a call for her assassination,
  then asking the American people to disarm is calling for
  their genocide. -- Jeff Ingebritson
---
 Tomorrow: the 285th anniversary of John Peter Zenger's acquittal

Re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

[John Wilcock]

On 2020-08-01 21:23, bugzilla-dae...@spamassassin.apache.org wrote:

> https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7826
> 
> --- Comment #58 from Kevin A. McGrail  ---
> (In reply to John Hardin from comment #57) (In reply to Kevin A. McGrail from 
> comment #55)
> 
> This isn't a plugin to disable features (i.e. deprecate), it's to enable 
> them. 
> So name it "EnableDeprecatedTerminology.pm"
> 
> I second the objection to "RaciallyCharged.pm". Doing that is essentially
> scolding anyone who enables backwards compatibility features.

The RaciallyCharged plugin doesn't enabled deprecated terminology, it
enables
the racially charged language. It's used in the rules specifically for
this
issue and the tests as well for backwards compatible.  It won't be
suitable as
a generic plugin.  The plugin describes exactly what the plugin does and
I
stand by the name.  People should stop using the language. 

As you cannot fail to be aware if you read even a fraction of the list
messages on this topic, there is absolutely no consensus that
blacklist/whitelist etc. are racially charged terms. Some perceive them
as such, sure, but others disagree, and indeed some disagree rather
strongly. It would seem fitting to avoid a divisive name for re-enabling
the terms. 

What is indisputable is that the project has chosen to deprecate the
terms, regardless of the reasons for that deprecation. It is equally
indisputable that the plugin is for backward compatibility reasons. So
how about EnableDeprecatedTerminology or
EnableBackwardCompatibilityTerminology, which would be accurate and far
less divisive names. I suppose it might be argued that another plugin
might be needed in the future for enabling terms deprecated for other
reasons. If that is a worry, then call this one
EnableDeprecatedBlackWhiteTerminology or
EnableBackCompatBlackWhiteTerminology.  

-- 
John

RE: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Marc Roos]

>> You go shut your piehole

Ehhh, who exactly? Having a nice evening with a vodka bottle? ;)

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Ted Mittelstaedt]

You go shut your piehole

Woke white guys who know best about racism against blacks and who use a 
domain name that insults native Americans have spoken!!!


Black people and people of color need to go sit down and shut up while 
woke white guys who know best for them do what is best for them.



Ted

PS  Just be happy they haven't renamed the program "spamstopper" because 
the name Assassin isn't I CAVE-approved  (although icave
disbanded when the woke people who hated warner brothers succeeded in 
getting Bugs Bunny off the air...was replaced by a bunch of other 
splinter groups)


Have sympathy for them it's really tiring to be so woke

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Riccardo Alfieri]

On 20/07/20 19:31, John Hardin wrote:



Apologies for not clarifying that detail; I was aware of it. I did 
hedge by saying "(potentially) subject to renaming".



No apologies necessary, it wasn't directed to you :)

I'm just trying to raise awareness that, while changing things is 
possible, it must be done with proper testing and communication to all 
the parties involved


--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[John Hardin]

On Mon, 20 Jul 2020, Riccardo Alfieri wrote:


On 20/07/20 19:01, Martin Gregorie wrote:


Repeating previously posted info for completeness: one of my private
rules uses URIBL_BLACK as a subrule. I have no other potential conflicts
with SA rule name changes and no postprocessing that's dependent on SA
rule names.


Here just to say that URIBL Black is the official name that URIBL use 
for that blocklist (http://uribl.com/usage.shtml). If there will be a 
name change then a proposal should come from the URIBL team, not SA.


Apologies for not clarifying that detail; I was aware of it. I did hedge 
by saying "(potentially) subject to renaming".



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  If the rock of doom requires a gentle nudge away from Gaia to
  prevent a very bad day for Earthlings, NASA won’t be riding to the
  rescue. These days, NASA does dodgy weather research and outreach
  programs, not stuff in actual space with rockets piloted by
  flinty-eyed men called Buzz.   -- Daily Bayonet
---
 Today: the 51st anniversary of Apollo 11 landing on the Moon

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Riccardo Alfieri]

On 20/07/20 19:01, Martin Gregorie wrote:


Repeating previously posted info for completeness: one of my private
rules uses URIBL_BLACK as a subrule. I have no other potential conflicts
with SA rule name changes and no postprocessing that's dependent on SA
rule names.


Here just to say that URIBL Black is the official name that URIBL use 
for that blocklist (http://uribl.com/usage.shtml). If there will be a 
name change then a proposal should come from the URIBL team, not SA. If 
SA is not satisfied with the name it should drop the list from the rules 
if the URIBL team is not willing to comply to the name change.


I don't want to enter the discussion about what is good or not, I'm only 
concerned that these changes could impact other products in the SA universe


--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Martin Gregorie]

On Mon, 2020-07-20 at 09:30 -0700, John Hardin wrote:
> It would be helpful if we could be informed whether anyone has post-
> SA processing that looks for these rulenames in the SA hit results,
> e.g. for making message delivery decisions.
> 
Repeating previously posted info for completeness: one of my private
rules uses URIBL_BLACK as a subrule. I have no other potential conflicts
with SA rule name changes and no postprocessing that's dependent on SA
rule names.

Martin

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[John Hardin]

On Mon, 20 Jul 2020, Thom van der Boon wrote:


One example is that our IRS ("Belastingdienst") is whitelisted by the following 
rule:

whitelist_from_spf *@belastingdienst.nl


That configuration syntax will continue to be supported for at least one 
year after the release of SA 4.0 (i.e. it will not be dropped before the 
first release occurring after that year has passed).



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Back in 1969 the technology to fake a Moon landing didn't exist,
  but the technology to actually land there did.
  Today, it is the opposite.   -- unknown
---
 Today: the 51st anniversary of Apollo 11 landing on the Moon

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[John Hardin]

On Sun, 19 Jul 2020, Kevin A. McGrail wrote:


Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
USER_IN_WELCOMELIST_TO to assist those running older versions of
SpamAssassin get stock rulesets.

If you have custom scoring or any custom rules building on
USER_IN_WHITELIST_TO, please accept our apologies and change the
references to USER_IN_WELCOMELIST_TO.


These are the rulenames from the base rules that are (potentially) subject 
to renaming:


 HEADER_HOST_IN_BLACKLIST
 HEADER_HOST_IN_WHITELIST
 RCVD_IN_SEMBLACK
 SUBJECT_IN_BLACKLIST
 SUBJECT_IN_WHITELIST
 URI_HOST_IN_BLACKLIST
 URI_HOST_IN_WHITELIST
 URIBL_BLACK
 USER_IN_BLACKLIST
 USER_IN_BLACKLIST_TO
 USER_IN_DEF_WHITELIST
 USER_IN_DKIM_WHITELIST
 USER_IN_SPF_WHITELIST
 USER_IN_WHITELIST
 USER_IN_WHITELIST_TO

(Some of these rules are historical and are currently disabled; they are 
included for completeness.)


It would be helpful if we could be informed whether anyone has post-SA 
processing that looks for these rulenames in the SA hit results, e.g. for 
making message delivery decisions.


Thank you.

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Back in 1969 the technology to fake a Moon landing didn't exist,
  but the technology to actually land there did.
  Today, it is the opposite.   -- unknown
---
 Today: the 51st anniversary of Apollo 11 landing on the Moon

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Philipp Ewald]

ah sorry i wrote that totally wrong...

i mean we have "whitelist_from" setting.

should i change that to "welcomelist_from" or to "welcome_from", because when changing from "whitelist" to 
"welcomelist" should  "welcomelist_from" be "right" but "welcome_from" sounds better.

So my second question is about how to automatically change that in 
configuration files?
sed -i 's/whitelist/welcomelist/g' 


Am 20.07.20 um 13:54 schrieb Marc Roos:


What is being used for mail that is not welcome, but still needs to be
allowed thru?



-Original Message-
To: users@spamassassin.apache.org
Subject: Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST
in process of being Renamed

can we use something like that or is there any special edit necessary?

sed -i 's/whitelist/welcomelist/g' $CONFIG

my setting "whitelist_from" to "welcomelist_from" || "welcome_from"?

Thanks

Am 19.07.20 um 18:09 schrieb Kevin A. McGrail:

All:

As of today, the configuration option WHITELIST_TO has been renamed
WELCOMELIST_TO with an alias for backwards compatibility.

Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
USER_IN_WELCOMELIST_TO to assist those running older versions of
SpamAssassin get stock rulesets.

If you have custom scoring or any custom rules building on
USER_IN_WHITELIST_TO, please accept our apologies and change the
references to USER_IN_WELCOMELIST_TO.

In order to remove racially charged configuration options, whitelist
will become welcomelist and blacklist will become blocklist.  More
changes will be coming for this with these small changes in the stock
ruleset.
Apologies for the disruption and thanks to those who are reporting
issues as we work through the changes.

Regards,
KAM






--
Philipp Ewald
Administrator

DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
Telefon: +49 221 6500-532, Fax: +49 221 6500-690, E-Mail: 
philipp.ew...@digionline.de

AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain

Informationen zum Datenschutz: www.digionline.de/ds

RE: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Marc Roos]

What is being used for mail that is not welcome, but still needs to be 
allowed thru?



-Original Message-
To: users@spamassassin.apache.org
Subject: Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST 
in process of being Renamed

can we use something like that or is there any special edit necessary?

sed -i 's/whitelist/welcomelist/g' $CONFIG

my setting "whitelist_from" to "welcomelist_from" || "welcome_from"?

Thanks

Am 19.07.20 um 18:09 schrieb Kevin A. McGrail:
> All:
> 
> As of today, the configuration option WHITELIST_TO has been renamed 
> WELCOMELIST_TO with an alias for backwards compatibility.
> 
> Additionally, the rule USER_IN_WHITELIST_TO has been renamed to 
> USER_IN_WELCOMELIST_TO to assist those running older versions of 
> SpamAssassin get stock rulesets.
> 
> If you have custom scoring or any custom rules building on 
> USER_IN_WHITELIST_TO, please accept our apologies and change the 
> references to USER_IN_WELCOMELIST_TO.
> 
> In order to remove racially charged configuration options, whitelist 
> will become welcomelist and blacklist will become blocklist.  More 
> changes will be coming for this with these small changes in the stock 
> ruleset.
> Apologies for the disruption and thanks to those who are reporting 
> issues as we work through the changes.
> 
> Regards,
> KAM
> 

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Philipp Ewald]

can we use something like that or is there any special edit necessary?

sed -i 's/whitelist/welcomelist/g' $CONFIG

my setting "whitelist_from" to "welcomelist_from" || "welcome_from"?

Thanks

Am 19.07.20 um 18:09 schrieb Kevin A. McGrail:

All:

As of today, the configuration option WHITELIST_TO has been renamed
WELCOMELIST_TO with an alias for backwards compatibility.

Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
USER_IN_WELCOMELIST_TO to assist those running older versions of
SpamAssassin get stock rulesets.

If you have custom scoring or any custom rules building on
USER_IN_WHITELIST_TO, please accept our apologies and change the
references to USER_IN_WELCOMELIST_TO.

In order to remove racially charged configuration options, whitelist
will become welcomelist and blacklist will become blocklist.  More
changes will be coming for this with these small changes in the stock
ruleset.
Apologies for the disruption and thanks to those who are reporting
issues as we work through the changes.

Regards,
KAM



--
Philipp Ewald
Administrator

DigiOnline GmbH, Probsteigasse 15 - 19, 50670 Köln
Telefon: +49 221 6500-532, Fax: +49 221 6500-690, E-Mail: 
philipp.ew...@digionline.de

AG Köln HRB 27711, St.-Nr. 5215 5811 0640
Geschäftsführer: Werner Grafenhain

Informationen zum Datenschutz: www.digionline.de/ds

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Thom van der Boon]

Dear Kevin, 

I maintain a rule set specificly targeted at the Dutch language: [ 
https://dutchspamassassinrules.nl/DSR/DSR.cf | 
https://dutchspamassassinrules.nl/DSR/DSR.cf ] 

One example is that our IRS ("Belastingdienst") is whitelisted by the following 
rule: 

whitelist_from_spf *@belastingdienst.nl 

Our IRS ("Belastingdienst") uses DKIM, SPF and DMARC, so fake messages are 
extremely easy to detect. 

This list (DSR) is used by a number of mailservers in the Netherlands. So the 
changes that were made. will impact all servers that use the DSR 


Met vriendelijke groet, Best regards, 


Thom van der Boon 
E-Mail: t...@vdb.nl 


Van: "Kevin A. McGrail"  
Aan: "Thom van der Boon"  
Cc: "SA Mailing list" , "SpamAssassin Devel 
List"  
Verzonden: Zondag 19 juli 2020 19:56:34 
Onderwerp: Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in 
process of being Renamed 

We only publish one set of rules so you will see that become welcome instead of 
white. If you are using a modern day 3.4.3 or greater, you can likely prepare 
for the changes now by adding both to meta rules. Can you show an example of 
your dependency? 

On Sun, Jul 19, 2020, 13:06 Thom van der Boon < [ mailto:t...@vdb.nl | 
t...@vdb.nl ] > wrote: 



Dear Kevin, 

Could you please clearify what versions are affected in these changes? 

My own rules rely heavily on whitelist_from_spf 

Met vriendelijke groet, Best regards, 


Thom van der Boon 
E-Mail: [ mailto:t...@vdb.nl | t...@vdb.nl ] 



Van: "Kevin A. McGrail" < [ mailto:kmcgr...@apache.org | kmcgr...@apache.org ] 
> 
Aan: "SA Mailing list" < [ mailto:users@spamassassin.apache.org | 
users@spamassassin.apache.org ] >, "SpamAssassin Devel List" < [ 
mailto:d...@spamassassin.apache.org | d...@spamassassin.apache.org ] > 
Verzonden: Zondag 19 juli 2020 18:09:36 
Onderwerp: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in 
process of being Renamed 

All: 

As of today, the configuration option WHITELIST_TO has been renamed 
WELCOMELIST_TO with an alias for backwards compatibility. 

Additionally, the rule USER_IN_WHITELIST_TO has been renamed to 
USER_IN_WELCOMELIST_TO to assist those running older versions of 
SpamAssassin get stock rulesets. 

If you have custom scoring or any custom rules building on 
USER_IN_WHITELIST_TO, please accept our apologies and change the 
references to USER_IN_WELCOMELIST_TO. 

In order to remove racially charged configuration options, whitelist 
will become welcomelist and blacklist will become blocklist. More 
changes will be coming for this with these small changes in the stock 
ruleset. 
Apologies for the disruption and thanks to those who are reporting 
issues as we work through the changes. 

Regards, 
KAM 

-- 

Kevin A. McGrail 
kmcgr...@apache.org 

Member, Apache Software Foundation 
Chair Emeritus Apache SpamAssassin Project 
[ https://www.linkedin.com/in/kmcgrail | https://www.linkedin.com/in/kmcgrail ] 
- 703.798.0171 

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[@lbutlr]

On 19 Jul 2020, at 21:23, Olivier  wrote:
> Please consider adding an easy way to turn the backward compatibility on
> and off.

I would suggest to settings, one that warns the definition has changed and one 
that errors on the old term rather than just a "turn on compatibility" which 
will mean that some people just turnout on an then never update.



-- 
'Never build a dungeon you wouldn't be happy to spend the night in
yourself,' said the Patrician (...). 'The world would be a
happier place if more people remembered that.' --Guards! Guards!

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[jdow]

On 20200719 18:02:18, John Hardin wrote:

On Sun, 19 Jul 2020, Loren Wilton wrote:

In other words, support both "black" and "block", and "white" and "welcome", 
for at least 3 months, I suggest.


The bug report that introduced this change claimed 100% backward compatability 
for at least one year, later changed to until 4.0 came out, whenever that will 
be.


You're misreading that. Backwards compatibility in the code will be maintained 
for at least one year after the 4.0 release, when the code changes take effect, 
and would not be removed until 4.1 is released if it has not been released by 
that point (which is unlikely - 4.0 and 4.1 released within one year?). So if 
4.1 was released within a year of 4.0, it would include backwards compatibility 
and that would remain until at least 4.2


Unfortunately some rule name changes are making it out ahead of the 4.0 release. 
We're working on addressing this, it should be a temporary condition.


Am I granted an "I told you so?" The results coming out of this betray a 
breathtaking level of arrogance and overt racism.


{o.o}

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Benny Pedersen]

Noel Butler skrev den 2020-07-20 05:35:


Just think of those 10's thousands of running spamassassin who are not
on these lists, all in for a shock when custom scripts start breaking.


lets hope rspamd being marked stable on gentoo before this shock happend 
:=)

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Loren Wilton]

The bug report that introduced this change claimed 100% backward 
compatability for at least one year, later changed to until 4.0 came out, 
whenever that will be.


You're misreading that. Backwards compatibility in the code will be 
maintained for at least one year after the 4.0 release,


Sorry about misreading that.

It's a shame that there is no requirement for backward compatability BEFORE 
the 4.0 release. Whenever that comes out.


   Loren

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Noel Butler]

On 20/07/2020 13:23, Olivier wrote:

> "Kevin A. McGrail"  writes:
> 
>> All:
>> 
>> As of today, the configuration option WHITELIST_TO has been renamed
>> WELCOMELIST_TO with an alias for backwards compatibility.
> 
> Kevin,
> 
> Please consider adding an easy way to turn the backward compatibility on
> and off.
> 
> So we, person in charge of mail systems, can find all the obscure places
> where the renaming will break something; because I am strongly beleiving
> that issues will arise from the less unsuspected places.
> 
> The compatibility enable option will allow us to run without
> compatibility, notice where the thing break and enable the compatibility
> while solving the issues. That will be the less damaging way for our
> users.

Just think of those 10's thousands of running spamassassin who are not
on these lists, all in for a shock when custom scripts start breaking. 

-- 
Regards,
Noel Butler 

This Email, including attachments, may contain legally privileged
information, therefore at all times remains confidential and subject to
copyright protected under international law. You may not disseminate
this message without the authors express written authority to do so. If
you are not the intended recipient, please notify the sender then delete
all copies of this message including attachments immediately.
Confidentiality, copyright, and legal privilege are not waived or lost
by reason of the mistaken delivery of this message.

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Olivier]

"Kevin A. McGrail"  writes:

> All:
>
> As of today, the configuration option WHITELIST_TO has been renamed
> WELCOMELIST_TO with an alias for backwards compatibility. 

Kevin,

Please consider adding an easy way to turn the backward compatibility on
and off.

So we, person in charge of mail systems, can find all the obscure places
where the renaming will break something; because I am strongly beleiving
that issues will arise from the less unsuspected places.

The compatibility enable option will allow us to run without
compatibility, notice where the thing break and enable the compatibility
while solving the issues. That will be the less damaging way for our
users.

Best regards,

Olivier


> Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
> USER_IN_WELCOMELIST_TO to assist those running older versions of
> SpamAssassin get stock rulesets.
>
> If you have custom scoring or any custom rules building on
> USER_IN_WHITELIST_TO, please accept our apologies and change the
> references to USER_IN_WELCOMELIST_TO.
>
> In order to remove racially charged configuration options, whitelist
> will become welcomelist and blacklist will become blocklist.  More
> changes will be coming for this with these small changes in the stock
> ruleset.
> Apologies for the disruption and thanks to those who are reporting
> issues as we work through the changes.
>
> Regards,
> KAM

-- 

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[John Hardin]

On Sun, 19 Jul 2020, Loren Wilton wrote:

In other words, support both "black" and "block", and "white" and 
"welcome", for at least 3 months, I suggest.


The bug report that introduced this change claimed 100% backward 
compatability for at least one year, later changed to until 4.0 came out, 
whenever that will be.


You're misreading that. Backwards compatibility in the code will be 
maintained for at least one year after the 4.0 release, when the code 
changes take effect, and would not be removed until 4.1 is released if 
it has not been released by that point (which is unlikely - 4.0 and 4.1 
released within one year?). So if 4.1 was released within a year of 4.0, 
it would include backwards compatibility and that would remain until at 
least 4.2


Unfortunately some rule name changes are making it out ahead of the 4.0 
release. We're working on addressing this, it should be a temporary 
condition.



--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Back in 1969 the technology to fake a Moon landing didn't exist,
  but the technology to actually land there did.
  Today, it is the opposite.   -- unknown
---
 Tomorrow: the 51st anniversary of Apollo 11 landing on the Moon

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Loren Wilton]

In other words, support both "black" and "block", and "white" and 
"welcome",

for at least 3 months, I suggest.


The bug report that introduced this change claimed 100% backward 
compatability for at least one year, later changed to until 4.0 came out, 
whenever that will be.


Of course it doesn't actually work that way, as you have observed. But that 
is just your problem, not SA's, as you can determine from this thread.



   Loren

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Antony Stone]

On Sunday 19 July 2020 at 19:56:34, Kevin A. McGrail wrote:

> We only publish one set of rules so you will see that become welcome
> instead of white.

My feeling on this is that such a breaking change requires a fairly lengthy 
backward-compatible transition period (with appropriate warning messages for 
those still using the old terminology, but not such that it no longer works), 
rather than just switching over suddenly from "old" to "new" with no "dual 
use" interim period.

In other words, support both "black" and "block", and "white" and "welcome", 
for at least 3 months, I suggest.


Antony.

-- 
What do you call a dinosaur with only one eye?  A Doyouthinkesaurus.

   Please reply to the list;
 please *don't* CC me.

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Kevin A. McGrail]

We only publish one set of rules so you will see that become welcome
instead of white.  If you are using a modern day 3.4.3 or greater, you can
likely prepare for the changes now by adding both to meta rules.  Can you
show an example of your dependency?

On Sun, Jul 19, 2020, 13:06 Thom van der Boon  wrote:

> Dear Kevin,
>
> Could you please clearify what versions are affected in these changes?
>
> My own rules rely heavily on whitelist_from_spf
>
> Met vriendelijke groet, Best regards,
>
>
> Thom van der Boon
> E-Mail: t...@vdb.nl
>
>
> --
> *Van: *"Kevin A. McGrail" 
> *Aan: *"SA Mailing list" , "SpamAssassin
> Devel List" 
> *Verzonden: *Zondag 19 juli 2020 18:09:36
> *Onderwerp: *IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST
> in process of being Renamed
>
> All:
>
> As of today, the configuration option WHITELIST_TO has been renamed
> WELCOMELIST_TO with an alias for backwards compatibility.
>
> Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
> USER_IN_WELCOMELIST_TO to assist those running older versions of
> SpamAssassin get stock rulesets.
>
> If you have custom scoring or any custom rules building on
> USER_IN_WHITELIST_TO, please accept our apologies and change the
> references to USER_IN_WELCOMELIST_TO.
>
> In order to remove racially charged configuration options, whitelist
> will become welcomelist and blacklist will become blocklist.  More
> changes will be coming for this with these small changes in the stock
> ruleset.
> Apologies for the disruption and thanks to those who are reporting
> issues as we work through the changes.
>
> Regards,
> KAM
>
> --
>
> Kevin A. McGrail
> kmcgr...@apache.org
>
> Member, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171
>

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Thom van der Boon]

Dear Kevin, 

Could you please clearify what versions are affected in these changes? 

My own rules rely heavily on whitelist_from_spf 

Met vriendelijke groet, Best regards, 


Thom van der Boon 
E-Mail: t...@vdb.nl 



Van: "Kevin A. McGrail"  
Aan: "SA Mailing list" , "SpamAssassin Devel 
List"  
Verzonden: Zondag 19 juli 2020 18:09:36 
Onderwerp: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in 
process of being Renamed 

All: 

As of today, the configuration option WHITELIST_TO has been renamed 
WELCOMELIST_TO with an alias for backwards compatibility. 

Additionally, the rule USER_IN_WHITELIST_TO has been renamed to 
USER_IN_WELCOMELIST_TO to assist those running older versions of 
SpamAssassin get stock rulesets. 

If you have custom scoring or any custom rules building on 
USER_IN_WHITELIST_TO, please accept our apologies and change the 
references to USER_IN_WELCOMELIST_TO. 

In order to remove racially charged configuration options, whitelist 
will become welcomelist and blacklist will become blocklist. More 
changes will be coming for this with these small changes in the stock 
ruleset. 
Apologies for the disruption and thanks to those who are reporting 
issues as we work through the changes. 

Regards, 
KAM 

-- 

Kevin A. McGrail 
kmcgr...@apache.org 

Member, Apache Software Foundation 
Chair Emeritus Apache SpamAssassin Project 
https://www.linkedin.com/in/kmcgrail - 703.798.0171 

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Kevin A. McGrail]

> i got the warning at the daily 12:30 AM lint today as well and as said
> that started long *after that* thread

If you are running ruleset 1880040 and you are running spamassassin
--lint and getting an error, please post the error and the version of SA
you are using.


> frankly where i start to puke is "WHITELIST_TO" and
> "USER_IN_WHITELIST_TO" are renamed, it obviously affects users running
> *stable releases* and you guys are not capable to rename every
> appareance of BLACKLIST and WHITELIST at the same time

It's a balance of trying to support some of the older installs and the
new changes.  We'll dial it in and appreciate the feedback on getting
the changes to work.  Really immune to any complaints about the overall
changes though. They are coming and complaining about it is a waste of
your time.


> meta  CUST_SHORTCIRCUIT1  (ALL_TRUSTED || USER_IN_ALL_SPAM_TO ||
> USER_IN_WHITELIST || USER_IN_SPF_WHITELIST || USER_IN_DKIM_WHITELIST)
> score USER_IN_DKIM_WHITELIST -100.0
> score USER_IN_SPF_WHITELIST -100.0

On your local version, if you add a score USER_IN_DKIM_WELCOMLIST -100.0
which does not exist yet, you should get just a warning.  If so,
changing that one meta and those two scores preemptively will prepare
you for the change. 

e.g. meta CUST_SHORTCIRCUIT1 (ALL_TRUSTED || USER_IN_ALL_SPAM_TO ||
USER_IN_WELCOMELIST || USER_IN_WHITELIST || ...

I think you said you were on fedora 3.4.4, so please let me know.

Regards,

KAM


-- 
Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Kevin A. McGrail]

> are you guys crazy doing that to *existing* stable installs and what
> does that mean for setups with "warn: rules: error: unknown eval
> 'check_to_in_whitelist' for USER_IN_WELCOMELIST_TO"

I've heard back from testers using 3.3.1 to 3.4.2 that the issue is
resolved re: the eval or unknown rule for descriptions.

The issue this morning is dealing with local rescoring or local rules
that use rules that are being renamed in stock ruleset.  Do you have any
local rescoring or local rules built on *WHITELIST* or *BLACKLIST*?  If
not, the issue should be minor. 

Regards,

KAM


-- 

Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

IMPORTANT NOTICE: Rules referencing WHITELIST or BLACKLIST in process of being Renamed

[Kevin A. McGrail]

All:

As of today, the configuration option WHITELIST_TO has been renamed
WELCOMELIST_TO with an alias for backwards compatibility. 

Additionally, the rule USER_IN_WHITELIST_TO has been renamed to
USER_IN_WELCOMELIST_TO to assist those running older versions of
SpamAssassin get stock rulesets.

If you have custom scoring or any custom rules building on
USER_IN_WHITELIST_TO, please accept our apologies and change the
references to USER_IN_WELCOMELIST_TO.

In order to remove racially charged configuration options, whitelist
will become welcomelist and blacklist will become blocklist.  More
changes will be coming for this with these small changes in the stock
ruleset.
Apologies for the disruption and thanks to those who are reporting
issues as we work through the changes.

Regards,
KAM

-- 

Kevin A. McGrail
kmcgr...@apache.org

Member, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

[Antony Stone]

On Friday 17 July 2020 at 19:17:42, Ted Mittelstaedt wrote:

> this entire "movement" about changing language boiled down is nothing more
> than yet another example of white people deciding what is best for people of
> color - like has been going on for centuries.

I applaud your comment, but I have to say that I think that where it matters 
it is falling on deaf ears.
 
> Let me be the first white man to extend an apology to the few people of
> color on these projects that we never actually bothered asking your
> opinions on something we had no business mucking around with.

Me 2°


Antony.

-- 
Why are sea-faring brigands unable to calculate the circumference of a circle?
Because they guess the value of Pi.
(Sorry, this joke only really works well in German).

   Please reply to the list;
 please *don't* CC me.

Re: IMPORTANT NOTICE FOR PEOPLE RUNNING TRUNK re: [Bug 7826] Improve language around whitelist/blacklist and master/slave

[Ted Mittelstaedt]

I think this bit is finally dying down so I will merely point out as the 
last, final nail in the coffin on all of this, that the majority of 
people on both the Apache and the Linux projects (as well as the other
larger commercial entities like Google, etc. that are engaged in this) 
are NOT "people of color" and this entire "movement" about changing 
language boiled down is nothing more than yet another example of white 
people deciding what is best for people of color - like has been going 
on for centuries.


In short, doing this DOES NOT apply ANY more legitimacy to the majority
white on social issues that are in control of these projects than they 
had before.


If the "votes" had been RESTRICTED to only people of color who were on
these projects - THEN they would have been legitimate.  Of course the
majority white would have been embarrassed if the few people of color
members voted to change nothing so they absolutely weren't going to give
them a chance to do that.

Most people of color undoubtedly prefer that the members of these 
projects stick to the technology and stay the fark out of the social

end of things.

Much like the Abortion debates were men have zero zilch business being
involved in the debate, whites really have zero zilch business being
involved in this discussion, either.

The Linux Torvalds thing is just the capstone of White Privilege played
out since HE IS WHITE.

Let me be the first white man to extend an apology to the few people of 
color on these projects that we never actually bothered asking your 
opinions on something we had no business mucking around with.


Ted

On 7/16/2020 1:49 AM, Gaute Gløersen wrote:

And Linus Torvalds has announced this for the Linux kernel:

https://www.theregister.com/2020/07/13/linux_adopts_inclusive_language/

/Gaute G

tor. 16. jul. 2020 kl. 08:14 skrev Thomas Cameron
mailto:thomas.came...@camerontech.com>>:

On 7/10/20 4:33 AM, jdow wrote:
 >
 > Are we now going to be afraid of the unwelcome rather than the dark?
 > Are we going to shine a welcome on problems rather than light?
 >
 > You guys are MAKING problems where they do not exist. Shame on you,
 > children.
 >
 > {^_^}

Nah, you're clinging to old, exclusionary language and behavior when
being inclusive is so damned easy.

Shame on you, old-timer. Be better than this.

Thomas