Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 21:28, John Hardin wrote:


On Mon, 19 Apr 2021, Bill Cole wrote:


On 19 Apr 2021, at 11:05, Matus UHLAR - fantomas wrote:


On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks are 
all set correctly... I had a long discussion with this mailing 
list on the subject last year and got excellent help on 
resolving that! :)



On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify KAM_DMARC_REJECT 
to not hit if ALL_TRUSTED is hit.



On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:
that would cause problems if you set up trusted_servers to any 
foreign server

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

That raises the question of why we don't have an ALL_INTERNAL rule.


&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


I don't think that works if X-Spam-Relays-External is empty, i.e. all 
relays are internal.


...so:

  header  ALL_INTERNAL  X-Spam-Relays-External =~ /^$/

?


Actually, what I committed earlier today in my sandbox and will move to 
the main rules tree if it doesn't do anything crazy in masschecks:


describe __NO_EXTERNALS No external relays
header   __NO_EXTERNALS X-Spam-Relays-External =~ /^$/

describe ALL_INTERNAL   Has only internal relays
meta ALL_INTERNAL   __NO_EXTERNALS && !NO_RELAYS
tflags   ALL_INTERNAL   nice


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

Re: Spamassassin goes to folder spam

[John Hardin]

On Tue, 20 Apr 2021, mau...@gmx.ch wrote:


if header :contains "To" users@spamassassin.apache.org
  {


This header might be a better check:

   List-Id: 


--
 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
---
  Our politicians should bear in mind the fact that
  the American Revolution was touched off by the then-current
  government attempting to confiscate firearms from the people.
---
 Today: the 246th anniversary of The Shot Heard 'Round The World

Re: KAM_DMARC_REJECT on internal emails

[John Hardin]

On Mon, 19 Apr 2021, Bill Cole wrote:


On 19 Apr 2021, at 11:05, Matus UHLAR - fantomas wrote:


On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks are all 
set correctly... I had a long discussion with this mailing list on the 
subject last year and got excellent help on resolving that! :)



On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify KAM_DMARC_REJECT to not 
hit if ALL_TRUSTED is hit.



On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:
that would cause problems if you set up trusted_servers to any foreign 
server

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

That raises the question of why we don't have an ALL_INTERNAL rule.


&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


I don't think that works if X-Spam-Relays-External is empty, i.e. all relays 
are internal.


...so:

  header  ALL_INTERNAL  X-Spam-Relays-External =~ /^$/

?


--
 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
---
  Our politicians should bear in mind the fact that
  the American Revolution was touched off by the then-current
  government attempting to confiscate firearms from the people.
---
 Today: the 246th anniversary of The Shot Heard 'Round The World

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 18:25, RW wrote:


On Mon, 19 Apr 2021 15:54:00 -0400
Bill Cole wrote:




It's clear to me that excluding the original message (given as an
example by the OP in a side-branch of this thread) from DMARC
verification could be done with a ALL_INTERNAL


I've been a bit distracted today and I've already misunderstood you
twice, but I still don't see what problem using ALL_INTERNAL instead
ALL_TRUSTED actually solves.


Discriminating between machines you trust to write honest Received 
headers (trusted) and those which you accept unsigned mail from 
(internal.)




There was some talk about mail from third-party external trusted
networks, but I was unclear about the problem. What using ALL_INTERNAL
gives you in that case is the possibility of getting  KAM_DMARC_REJECT
even when you have ALL_TRUSTED.


Precisely.
The original problem was messages originating internally which were not 
yet signed being caught by KAM_DMARC_REJECT because the local domain 
publishes p=reject.
I suggested exempting messages hitting ALL_TRUSTED from 
KAM_DMARC_REJECT.
Matus noted correctly that doing so with external machines in 
trusted_networks could result in "problems" i.e. allowing unsigned (i.e. 
fake) messages to bypass KAM_DMARC_REJECT because they are originating 
on a machine which is trusted not to write bogus Received headers. Note 
that a machine in trusted_networks is NOT necessarily presumed to not 
originate spam.
I proposed (and have committed to my sandbox) an ALL_INTERNAL rule which 
could be used to exempt mail which has originated on internal networks 
from hitting KAM_DMARC_REJECT even with n o signature and a p=reject 
policy for the author's domain.


Is that any more clear?

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

Re: Spamassassin goes to folder spam

[Benny Pedersen]

On 2021-04-20 01:12, mau...@gmx.ch wrote:

Hello

Asking for litle help…. Doevecot and sieve are running fine…. One
thing now, if receiving mail from Users-spamassassin

This mail will by forwarding from sieve to folder spam. I didn't see
why this will transfer there.

Dovecot 2.3.4.1 (f79e8e7e4) - Debain 10

Sieve

if header :contains "To" users@spamassassin.apache.org {

  fileinto "INBOX.Spamassassin";


  stop;



}

if header :contains "X-Spam-Flag" "Yes" {

  fileinto :create "Junk";

  stop;

}




X-Spam-Flag: YES



X-Spam-Flag: NO


multiple spamassassin versions or not same add header can make this

but easy fix in sieve, see above

Re: Spamassassin goes to folder spam

[Arne Jensen]

Den 20-04-2021 kl. 01:12 skrev mau...@gmx.ch:
>
> Hello
>
> Asking for litle help…. Doevecot and sieve are running fine…. One
> thing now, if receiving mail from Users-spamassassin
>
> This mail will by forwarding from sieve to folder spam. I didn’t see
> why this will transfer there.
>
Your message has two X-Spam-Flag's, one with YES, and another one with
NO, and then you aren't stopping the Sieve parsing.

>  
>
> Dovecot 2.3.4.1 (f79e8e7e4) - Debain 10
>
>  
>
> Sieve
>
>  
>
> if header :contains "To" users@spamassassin.apache.org
>  {
>
>   fileinto "INBOX.Spamassassin";
>
> }
>
> if header :contains "X-Spam-Flag" "Yes" {
>
>   fileinto :create "Junk";
>
>   stop;
>
> }
>
You could add "stop;" to the first one, where you file the message into
INBOX.Spamassassin, which means if it moves the message for you due to a
match, it won't go further with the check on the spam flag for that
particular message.

> --
>
> [...]
>
> Envelope-To: mau...@gmx.ch 
>
> X-GMX-Antispam: 5 (nemesis mail header analyzer); Detail=V3;
>
> X-Spam-Flag: YES
>
> X-UI-Filterresults: junk:10;V03:K0:oQ58xS3PZ3o=:ui
>
> X-UI-Loop:V01:NQ+uvMhGdNE=:SW
>
> X-Spam-Flag: NO
>
From your own snippet of headers, as you can see above, it appears like
you are having two different X-Spam-Flag's to match against, which will
cause some complications and potentially unpredictable results...

-- 
Med venlig hilsen / Kind regards,
Arne Jensen

Spamassassin goes to folder spam

[mauric]

Hello

Asking for litle help.. Doevecot and sieve are running fine.. One thing now,
if receiving mail from Users-spamassassin

This mail will by forwarding from sieve to folder spam. I didn't see why
this will transfer there.



Dovecot 2.3.4.1 (f79e8e7e4) - Debain 10



Sieve



if header :contains "To" users@spamassassin.apache.org
  {

  fileinto "INBOX.Spamassassin";

}

if header :contains "X-Spam-Flag" "Yes" {

  fileinto :create "Junk";

  stop;

}

--

Return-Path: mau...@gmx.ch 

Delivered-To: mauri...@domain.ch 

Received: from nmail.caloro.ch

by nmail.caloro.ch with LMTP

id cxP8HP/ffWDaKwAAmDN1Rg

(envelope-from mau...@gmx.ch  )

for mauri...@domain.ch  ; Mon, 19
Apr 2021 21:54:39 +0200

Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=212.227.15.15;
helo=mout.gmx.net; envelope-from=mau...@gmx.ch
 ; receiver=

DMARC-Filter: OpenDMARC Filter v1.3.2 nmail.caloro.ch C914140201

Authentication-Results: nmail.caloro.ch mail.caloro.ch caloro.ch; dmarc=none
(p=none dis=none) header.from=billmail.scconsult.com

Authentication-Results: nmail.caloro.ch mail.caloro.ch caloro.ch; spf=pass
smtp.mailfrom=mau...@gmx.ch 

DKIM-Filter: OpenDKIM Filter v2.11.0 nmail.caloro.ch C914140201

Mailing-List: contact users-h...@spamassassin.apache.org
 ; run by ezmlm

Precedence: bulk

list-help: mailto:users-h...@spamassassin.apache.org

list-unsubscribe: mailto:users-unsubscr...@spamassassin.apache.org

List-Post:  
mailto:users@spamassassin.apache.org

List-Id: 

Delivered-To: mailing list users@spamassassin.apache.org


X-Spam-Score: -0.001

X-Spam-Level:

X-Spam-Status: No, score=0.2 required=5.0
tests=AWL,FREEMAIL_FORGED_FROMDOMAIN,


FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,

SPF_PASS,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no

version=3.4.6

Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=67.149.19.3;
helo=bigsky.scconsult.com;
envelope-from=sausers-20150...@billmail.scconsult.com
 ;
receiver=

From: "Bill Cole" sausers-20150...@billmail.scconsult.com


To: users@spamassassin.apache.org 

Subject: Re: KAM_DMARC_REJECT on internal emails

Date: Mon, 19 Apr 2021 15:54:00 -0400

Message-ID:

a6d58fa5-dcc4-4618-a6a9-0dc9065fe...@billmail.scconsult.com

In-Reply-To: 20210419195718.1fc40...@gumby.homeunix.com


References:
20210419220521.horde.x77ptxnvnoymeq5bd2xj...@mail.simonandkate.net


MIME-Version: 1.0

Content-Type: text/plain; format=flowed

Mail-Copies-To: nobody

X-Spam-Source:  on  via  in en

X-Spam-Hops:

Envelope-To: mau...@gmx.ch 

X-GMX-Antispam: 5 (nemesis mail header analyzer); Detail=V3;

X-Spam-Flag: YES

X-UI-Filterresults: junk:10;V03:K0:oQ58xS3PZ3o=:ui

X-UI-Loop:V01:NQ+uvMhGdNE=:SW

X-Spam-Flag: NO

X-UI-Out-Filterresults: notjunk:1;V03:K0:oU0GgD86eVw=:3o

X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on nmail.caloro.ch

X-Virus-Scanned: clamav-milter 0.102.4 at nmail.caloro.ch

X-Virus-Status: Clean



Thanks for possible update

Re: KAM_DMARC_REJECT on internal emails

[RW]

On Mon, 19 Apr 2021 15:54:00 -0400
Bill Cole wrote:


> 
> It's clear to me that excluding the original message (given as an 
> example by the OP in a side-branch of this thread) from DMARC 
> verification could be done with a ALL_INTERNAL

I've been a bit distracted today and I've already misunderstood you
twice, but I still don't see what problem using ALL_INTERNAL instead 
ALL_TRUSTED actually solves. 

There was some talk about mail from third-party external trusted
networks, but I was unclear about the problem. What using ALL_INTERNAL
gives you in that case is the possibility of getting  KAM_DMARC_REJECT
even when you have ALL_TRUSTED.

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 14:57, RW wrote:


On Mon, 19 Apr 2021 13:46:57 -0400
Bill Cole wrote:


On 19 Apr 2021, at 13:26, RW wrote:



I'm not 100% sure, but I think localhost, unlike private addresses,
is always internal/trusted.


I don't think that is relevant to the original message at hand or to
what I'm trying to match, which is the absence of any external
relays. As far as I can tell, it is impossible to make SA mark an
internal relay as external without there being an actual external
source.



See

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


Which describes the inverse problem: submission from an external source 
being treated as internal because a (presumably) trusted internal 
machine says that it is authenticated. I see that problem (although I 
have not tested it) but don't immediately know what the proper behavior 
is, as I've not tested the apparent weaknesses against possible 
legitimate structures like authenticated smarthost & forwarding.


It's clear to me that excluding the original message (given as an 
example by the OP in a side-branch of this thread) from DMARC 
verification could be done with a ALL_INTERNAL, regardless of the 
behavior in Bug 7590, because it originated at an internal IP.


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

Re: KAM_DMARC_REJECT on internal emails

[RW]

On Mon, 19 Apr 2021 13:46:57 -0400
Bill Cole wrote:

> On 19 Apr 2021, at 13:26, RW wrote:

> > I'm not 100% sure, but I think localhost, unlike private addresses,
> > is always internal/trusted.  
> 
> I don't think that is relevant to the original message at hand or to 
> what I'm trying to match, which is the absence of any external
> relays. As far as I can tell, it is impossible to make SA mark an
> internal relay as external without there being an actual external
> source.
> 

See

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

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 13:26, RW wrote:


On Mon, 19 Apr 2021 13:20:37 -0400
Bill Cole wrote:


On 19 Apr 2021, at 13:03, Matus UHLAR - fantomas wrote:


On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote:

I understand this as:

if mail was received by internal relay unauthenticated, it's
external,


On 19.04.21 12:49, Bill Cole wrote:

I cannot make SA behave that way.


why not?


When I provide SA with a message that has stepped through 2 internal
machines with no authentication, SA *DOES NOT* insert any information
about the relay host in X-Spam-Relays-External.


I'm not 100% sure, but I think localhost, unlike private addresses, is
always internal/trusted.


I don't think that is relevant to the original message at hand or to 
what I'm trying to match, which is the absence of any external relays. 
As far as I can tell, it is impossible to make SA mark an internal relay 
as external without there being an actual external source.


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

Re: Senderscore

[Simon Bressier]

And btw, usually on the DNS infos of Senderscores, you can see about 3
days of lag compared to their online interface, dunno if expected on
their side, or they're facing perf issues, but that service is not a
top priority at all at least

On Mon, Apr 19, 2021 at 7:29 PM Simon Bressier  wrote:
>
> Hi Simon,
>
> For info for few days now, the Senderscore DNS server is failing to
> answer. I've pinged one relation I have at Validity so they can dig on
> it.
>
> Senderscore via DNS is a legacy service they just maintain but dunno
> for how long... They are more on a mood to stop that service in the
> future to push to their API usage, and you ofc need to be client to
> use it :)
>
> On Mon, Apr 19, 2021 at 6:05 AM Simon Wilson  wrote:
> >
> > Spamassassin on my mail server uses a local dedicated caching DNS
> > server, and it is only service which uses it (it's specified in
> > local.cf).
> >
> > The last 3 days I have logged about 500 failed DNS query errors to
> > senderscore.com, e.g.:
> >
> > 19-Apr-2021 13:28:01.367 query-errors: info: client @0x7f31c334a9a0
> > 127.0.0.1#53689 (214.48.240.54.bl.score.senderscore.com): query failed
> > (SERVFAIL) for 214.48.240.54.bl.score.senderscore.com/IN/A at
> > ../../../bin/named/query.c:9385
> >
> > ...where in the month prior there were about 10 failures logged in
> > total. It's failing on what looks like every inbound email.
> >
> >  From what I can see it's a genuine blocklist lookup by SA...
> > (RCVD_IN_RP_RNBL in 20_dnsbl_tests.cf) but the error rate is strange.
> >
> > Am I the only one with high volume of lookup errors from that bl? :-)
> > or do I need to be looking for an issue locally...
> >
> > Simon.
> >
> > --
> > Simon Wilson
> > M: 0400 12 11 16
> >

Re: Senderscore

[Simon Bressier]

Hi Simon,

For info for few days now, the Senderscore DNS server is failing to
answer. I've pinged one relation I have at Validity so they can dig on
it.

Senderscore via DNS is a legacy service they just maintain but dunno
for how long... They are more on a mood to stop that service in the
future to push to their API usage, and you ofc need to be client to
use it :)

On Mon, Apr 19, 2021 at 6:05 AM Simon Wilson  wrote:
>
> Spamassassin on my mail server uses a local dedicated caching DNS
> server, and it is only service which uses it (it's specified in
> local.cf).
>
> The last 3 days I have logged about 500 failed DNS query errors to
> senderscore.com, e.g.:
>
> 19-Apr-2021 13:28:01.367 query-errors: info: client @0x7f31c334a9a0
> 127.0.0.1#53689 (214.48.240.54.bl.score.senderscore.com): query failed
> (SERVFAIL) for 214.48.240.54.bl.score.senderscore.com/IN/A at
> ../../../bin/named/query.c:9385
>
> ...where in the month prior there were about 10 failures logged in
> total. It's failing on what looks like every inbound email.
>
>  From what I can see it's a genuine blocklist lookup by SA...
> (RCVD_IN_RP_RNBL in 20_dnsbl_tests.cf) but the error rate is strange.
>
> Am I the only one with high volume of lookup errors from that bl? :-)
> or do I need to be looking for an issue locally...
>
> Simon.
>
> --
> Simon Wilson
> M: 0400 12 11 16
>

Re: KAM_DMARC_REJECT on internal emails

[RW]

On Mon, 19 Apr 2021 13:20:37 -0400
Bill Cole wrote:

> On 19 Apr 2021, at 13:03, Matus UHLAR - fantomas wrote:
> 
> >> On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote:  
> >>> I understand this as:
> >>>
> >>> if mail was received by internal relay unauthenticated, it's 
> >>> external,  
> >
> > On 19.04.21 12:49, Bill Cole wrote:  
> >> I cannot make SA behave that way.  
> >
> > why not?  
> 
> When I provide SA with a message that has stepped through 2 internal 
> machines with no authentication, SA *DOES NOT* insert any information 
> about the relay host in X-Spam-Relays-External.

I'm not 100% sure, but I think localhost, unlike private addresses, is
always internal/trusted. 

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 13:03, Matus UHLAR - fantomas wrote:


On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote:

I understand this as:

if mail was received by internal relay unauthenticated, it's 
external,


On 19.04.21 12:49, Bill Cole wrote:

I cannot make SA behave that way.


why not?


When I provide SA with a message that has stepped through 2 internal 
machines with no authentication, SA *DOES NOT* insert any information 
about the relay host in X-Spam-Relays-External.


e.g., these received headers:

Return-Path: 
	Received: from skinnyclam.scconsult.com (skinnyclam.scconsult.com 
[192.168.254.125])

by toaster.scconsult.com (Postfix) with ESMTP id 
4FP7Tb0wWWz5q7dl
for ; Mon, 19 Apr 2021 09:49:23 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1])
by skinnyclam.scconsult.com (Postfix) with ESMTP id D74214C88329
for ; Mon, 19 Apr 2021 09:49:22 -0400 (EDT)


Results in these RELAYS* assignments:

	Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSTRUSTED is 
now ready, value: [ ip=192.168.254.125 rdns=skinnyclam.scconsult.com 
helo=skinnyclam.scconsult.com by=bigsky.scconsult.com ident= 
envfrom=r...@skinnyclam.scconsult.com intl=1 id=4FP7Tb0wWWz5q7dl auth= 
msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=localhost 
by=skinnyclam.scconsult.com ident= envfrom=r...@skinnyclam.scconsult.com 
intl=1 id=D74214C88329 auth= msa=0 ]
	Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSUNTRUSTED is 
now ready, value:
	Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSINTERNAL is 
now ready, value: [ ip=192.168.254.125 rdns=skinnyclam.scconsult.com 
helo=skinnyclam.scconsult.com by=bigsky.scconsult.com ident= 
envfrom=r...@skinnyclam.scconsult.com intl=1 id=4FP7Tb0wWWz5q7dl auth= 
msa=0 ] [ ip=127.0.0.1 rdns=localhost helo=localhost 
by=skinnyclam.scconsult.com ident= envfrom=r...@skinnyclam.scconsult.com 
intl=1 id=D74214C88329 auth= msa=0 ]
	Apr 19 12:38:23.932 [14599] dbg: check: tagrun - tag RELAYSEXTERNAL is 
now ready, value:




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

Re: KAM_DMARC_REJECT on internal emails

[RW]

On Mon, 19 Apr 2021 19:03:55 +0200
Matus UHLAR - fantomas wrote:

> >On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote:  
> >> I understand this as:
> >>
> >> if mail was received by internal relay unauthenticated, it's
> >> external,  
> 
> On 19.04.21 12:49, Bill Cole wrote:
> >I cannot make SA behave that way.  
> 
> why not?
> 
> meta KAM_DMARC_REJECT  __LAST_EXTERNAL_RELAY_NO_AUTH &&
> !(DKIM_VALID_AU || SPF_PASS) && __KAM_DMARC_POLICY_REJECT
> 
> should avoid KAM_DMARC_REJECT if the mail was accepted authenticated
> by internal relay from external one.
> 


__LAST_EXTERNAL_RELAY_NO_AUTH will hit if an email arrived in the
internal network from external-trusted.

Re: KAM_DMARC_REJECT on internal emails

[RW]

On Mon, 19 Apr 2021 09:46:48 -0400
Bill Cole wrote:

> On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:
> 
> >> On 19 Apr 2021, at 8:42, Simon Wilson wrote:  
> >>> Yes, my trusted_networks, internal_networks and msa_networks are
> >>> all set correctly... I had a long discussion with this mailing
> >>> list on the subject last year and got excellent help on resolving
> >>> that! :)  
> >
> > On 19.04.21 09:17, Bill Cole wrote:  
> >> Then the most direct tactic would be to modify KAM_DMARC_REJECT to 
> >> not hit if ALL_TRUSTED is hit.  
> >
> > that would cause problems if you set up trusted_servers to any
> > foreign server
> > you trust not to fake headers.  
> 
> A valid point.

I assume you mean because it would still run on forwarded mail that
comes in via the trusted/external network.

This can be fixed by combining ALL_TRUSTED with a comparison of the
number of relays in external and untrusted. 

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote:

I understand this as:

if mail was received by internal relay unauthenticated, it's external,


On 19.04.21 12:49, Bill Cole wrote:

I cannot make SA behave that way.


why not?

meta KAM_DMARC_REJECT  __LAST_EXTERNAL_RELAY_NO_AUTH && !(DKIM_VALID_AU || 
SPF_PASS) && __KAM_DMARC_POLICY_REJECT

should avoid KAM_DMARC_REJECT if the mail was accepted authenticated by
internal relay from external one.

--
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.
WinError #98652: Operation completed successfully.

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote:

> I understand this as:
>
> if mail was received by internal relay unauthenticated, it's external,

I cannot make SA behave that way.


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

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

On 2021-04-19 17:30, Matus UHLAR - fantomas wrote:


I understand this as:

if mail was received by internal relay unauthenticated, it's external, 
and

therefore, should be subject to DMARC checks.


and 127.0.0.1 ::1 is hardcoded in spamasassasin, opendmarc skips if 
client ip is loopback interface


hope sa wont change this

consider NO_RELAYS aswell

no new rules is needed as bill added to test rules

if changes is really needed it would be a change in askdns to skip rules 
testing if mail only is in loopback


if !NO_RELAYS
 askdns 
endif

How do you set nomail for the List?

[Don Saklad]

How do you set nomail for the List? 
  

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks 
are all set correctly... I had a long discussion with this 
mailing list on the subject last year and got excellent help 
on resolving that! :)



On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify 
KAM_DMARC_REJECT to not hit if ALL_TRUSTED is hit.



On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:
that would cause problems if you set up trusted_servers to any 
foreign server

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

That raises the question of why we don't have an ALL_INTERNAL rule.



On 19 Apr 2021, at 11:05, Matus UHLAR - fantomas wrote:

&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


On 19.04.21 11:11, Bill Cole wrote:
I don't think that works if X-Spam-Relays-External is empty, i.e. all 
relays are internal.


I understand this as:

if mail was received by internal relay unauthenticated, it's external, and
therefore, should be subject to DMARC checks.


--
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.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 11:05, Matus UHLAR - fantomas wrote:


On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks are 
all set correctly... I had a long discussion with this mailing 
list on the subject last year and got excellent help on resolving 
that! :)



On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify KAM_DMARC_REJECT to 
not hit if ALL_TRUSTED is hit.



On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:
that would cause problems if you set up trusted_servers to any 
foreign server

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

That raises the question of why we don't have an ALL_INTERNAL rule.


&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


I don't think that works if X-Spam-Relays-External is empty, i.e. all 
relays are internal.



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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks are 
all set correctly... I had a long discussion with this mailing 
list on the subject last year and got excellent help on 
resolving that! :)



On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify KAM_DMARC_REJECT to 
not hit if ALL_TRUSTED is hit.



On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:
that would cause problems if you set up trusted_servers to any 
foreign server

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

That raises the question of why we don't have an ALL_INTERNAL rule.


&& __LAST_EXTERNAL_RELAY_NO_AUTH 

should do that. 



--
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.
My mind is like a steel trap - rusty and illegal in 37 states.

Re: KAM_DMARC_REJECT on internal emails

[Henrik K]

On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote:
>
> askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT 
> /^v=DMARC1;.*\bp=reject;/
> 
> run anyway? Or only if the resultant metas which call on them have a score
> value <> 0?

Askdns is like any other rule, it does what it's told to do with little
regard to anything else.  So yes you must disable it specifically, if you
don't want it to do something.

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

On 2021-04-19 14:42, Simon Wilson wrote:

  askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT
/^v=DMARC1;.*\bp=reject;/

run anyway?


note rulename starts with __ ?


Yes, and the doco says "...rules start with a double underscore, so
they are run and treated as having no score". So my question remains -
 It says "are run", so do those rules run the askdns queries if or if
not the subsequent meta rules are enabled or disabled? If I am not
using the meta rules (by setting scores to 0) do I also need to
disable the askdns rules to stop any unneeded dns calls?


yes all __ is runnined, for all mails, even if domains have no dmarc

its a waste rule if this happend

please in dev@ make that sql cached result or drop it


Or only if the resultant metas which call on them have a
score value <> 0?


opendkim opendmarc openarc sid-milter all have 127.0.0.1  whitelisted, 
and possible aswell ::1




They do yes. However I use fetchmail to retrieve emails from some
services; fetchmail presents into the inbound stack as being from
127.0.0.1 - so I do not use the milters' "whitelists" to decide
whether or not to run on inbound email, I use directed flow through
postfix and amavisd to decide whether or not the milters are run.


make your fetchmail use mda, problem solved


In the context of my query here on *outbound* email... I do *not* run
milters on outbound email, so it is only the KAM DMARC rules which
were running regardless which generated an issue.


fetchmail is inbound not outbound, kam rule is not a milter

the above kam rule is ment to be meta'ed with NO_RELAY or  ALL_TRUSTED 
or other tests that only hit on internal mails


so to ask now, did you configure trusted_networks internal_networks  
in spamassassin ?, it have to know all wan ips for your own server /  
servers


Yes, my trusted_networks, internal_networks and msa_networks are all
set correctly... I had a long discussion with this mailing list on the
 subject last year and got excellent help on resolving that! :)


sometimes its needed to debug

all the best

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

On 2021-04-19 15:46, Bill Cole wrote:

On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:


On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks are all 
set correctly... I had a long discussion with this mailing list on 
the subject last year and got excellent help on resolving that! :)


On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify KAM_DMARC_REJECT to 
not hit if ALL_TRUSTED is hit.


that would cause problems if you set up trusted_servers to any foreign 
server

you trust not to fake headers.


A valid point.

That raises the question of why we don't have an ALL_INTERNAL rule.


ALL_INTERNAL untrusted ... :=)

its simply not needed, else it would have being a bug in spamassassin 
2.6.4


i just repeat, make the trusted_network for ALL maintained wan ips

but dont do this if you have no root access to other mailservers

hopefully this is clear now

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 9:26, Matus UHLAR - fantomas wrote:


On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks are all 
set correctly... I had a long discussion with this mailing list on 
the subject last year and got excellent help on resolving that! :)


On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify KAM_DMARC_REJECT to 
not hit if ALL_TRUSTED is hit.


that would cause problems if you set up trusted_servers to any foreign 
server

you trust not to fake headers.


A valid point.

That raises the question of why we don't have an ALL_INTERNAL rule.

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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

On 19 Apr 2021, at 8:42, Simon Wilson wrote:
Yes, my trusted_networks, internal_networks and msa_networks are all 
set correctly... I had a long discussion with this mailing list on 
the subject last year and got excellent help on resolving that! :)


On 19.04.21 09:17, Bill Cole wrote:
Then the most direct tactic would be to modify KAM_DMARC_REJECT to not 
hit if ALL_TRUSTED is hit.


that would cause problems if you set up trusted_servers to any foreign server
you trust not to fake headers.

--
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.
"Where do you want to go to die?" [Microsoft]

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

On 19 Apr 2021, at 8:42, Simon Wilson wrote:

Yes, my trusted_networks, internal_networks and msa_networks are all 
set correctly... I had a long discussion with this mailing list on the 
subject last year and got excellent help on resolving that! :)


Then the most direct tactic would be to modify KAM_DMARC_REJECT to not 
hit if ALL_TRUSTED is hit.


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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

  askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT
/^v=DMARC1;.*\bp=reject;/

run anyway?


note rulename starts with __ ?


Yes, and the doco says "...rules start with a double underscore, so  
they are run and treated as having no score". So my question remains -  
It says "are run", so do those rules run the askdns queries if or if  
not the subsequent meta rules are enabled or disabled? If I am not  
using the meta rules (by setting scores to 0) do I also need to  
disable the askdns rules to stop any unneeded dns calls?





Or only if the resultant metas which call on them have a
score value <> 0?


opendkim opendmarc openarc sid-milter all have 127.0.0.1  
whitelisted, and possible aswell ::1




They do yes. However I use fetchmail to retrieve emails from some  
services; fetchmail presents into the inbound stack as being from  
127.0.0.1 - so I do not use the milters' "whitelists" to decide  
whether or not to run on inbound email, I use directed flow through  
postfix and amavisd to decide whether or not the milters are run.


In the context of my query here on *outbound* email... I do *not* run  
milters on outbound email, so it is only the KAM DMARC rules which  
were running regardless which generated an issue.


the above kam rule is ment to be meta'ed with NO_RELAY or  
ALL_TRUSTED or other tests that only hit on internal mails


so to ask now, did you configure trusted_networks internal_networks  
in spamassassin ?, it have to know all wan ips for your own server /  
servers


Yes, my trusted_networks, internal_networks and msa_networks are all  
set correctly... I had a long discussion with this mailing list on the  
subject last year and got excellent help on resolving that! :)


- End message from Benny Pedersen  -





--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

On 2021-04-19 14:05, Simon Wilson wrote:


   askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT
/^v=DMARC1;.*\bp=reject;/

run anyway?


note rulename starts with __ ?


Or only if the resultant metas which call on them have a
score value <> 0?


opendkim opendmarc openarc sid-milter all have 127.0.0.1 whitelisted, 
and possible aswell ::1


the above kam rule is ment to be meta'ed with NO_RELAY or ALL_TRUSTED or 
other tests that only hit on internal mails


so to ask now, did you configure trusted_networks internal_networks in 
spamassassin ?, it have to know all wan ips for your own server / 
servers

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

- Message from RW  -
   Date: Mon, 19 Apr 2021 12:47:02 +0100
   From: RW 
Subject: Re: KAM_DMARC_REJECT on internal emails
 To: users@spamassassin.apache.org



On Mon, 19 Apr 2021 16:36:58 +1000
Simon Wilson wrote:


Hi list,

- I'm running KAM rules in Spamassassin
- Postfix port 587-submitted email is sent to Amavisd (as a
content_filter) on port 10026 (tagged as ORIGINATING/MYNETS) and is
spam-checked and DKIM-signed on its way out the door, sent back to
Postfix at port 10025 for final delivery
- my domain has DMARC p=reject

If the final delivery is a local address, I'm getting some in-theory
valid but in practicality invalid Spamassassin scores... e.g. SA is
tagging those emails with KAM_DMARC_REJECT - as DMARC fails
(correctly). The sending and receiving IPs are all internal...



The KAM DMARC rules are simplistic. IIWY I'd override them.


Thanks... I'd reached the same conclusion. Seems crazy to run yet  
another set of tests when the emails I want to run those tests for I  
already have on the way in with e.g. OpenDMARC. So I've set the KAM  
DMARC rules to score 0. I have some alternate DMARC rules which only  
trigger on existing Authentication-results headers, rather than do a  
new test every time.


Question - with the KAM DMARC rules set to zero, do the dns tests, e.g.:

   askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT  
/^v=DMARC1;.*\bp=reject;/


run anyway? Or only if the resultant metas which call on them have a  
score value <> 0?



Simon

--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[RW]

On Mon, 19 Apr 2021 16:36:58 +1000
Simon Wilson wrote:

> Hi list,
> 
> - I'm running KAM rules in Spamassassin
> - Postfix port 587-submitted email is sent to Amavisd (as a  
> content_filter) on port 10026 (tagged as ORIGINATING/MYNETS) and is  
> spam-checked and DKIM-signed on its way out the door, sent back to  
> Postfix at port 10025 for final delivery
> - my domain has DMARC p=reject
> 
> If the final delivery is a local address, I'm getting some in-theory  
> valid but in practicality invalid Spamassassin scores... e.g. SA is  
> tagging those emails with KAM_DMARC_REJECT - as DMARC fails  
> (correctly). The sending and receiving IPs are all internal...
> 

The KAM DMARC rules are simplistic. IIWY I'd override them.

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

I'd say that a proper solution would be to DKIM-sign mail before it's
spam-scanned.


On 19.04.21 19:39, Simon Wilson wrote:

Good point. If DKIM is signed it should pass DMARC, even if SPF fails.

Amavisd handles both pieces, including DKIM signing... from looking  
at the headers it looks like Amavisd is spam scanning it first  
*then* DKIM signing it. I will post to the amavisd mailing list on  
that question...


DKIM-signing locally submitted mail prior to spam scanning would help us
here (and amavis is supposed to know local domains, unlike SA)



How does that work though... DKIM is supposed to sign LAST, not before  
a bunch of other headers are added...



It's not applicable for non-DKIM domains, which still can SPF pass and
therefore DMARC pass.


Surely SPF will never pass an internal only email, as you cannot have  
an internal IP address in your SPF record...

E.g. my SPF record is:
v=spf1 ip4:119.18.34.29 a:spf.email-hosting.net.au -all
Any internal assessment will fail when it sees 192.168.x.x as the sending IP.




but, the rule could apparently avoid locally-originated mail
(would help for non-DKIM domains).

meta KAM_DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) &&  
__KAM_DMARC_POLICY_REJECT


maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?


Am I reading the rule correctly that EITHER a fail DKIM or SPF will  
cause this to trip?


meta KAM_DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) &&  
__KAM_DMARC_POLICY_REJECT
describe KAM_DMARC_REJECT DKIM has Failed or SPF has failed on the  
message and the domain has a DMARC reject policy

scoreKAM_DMARC_REJECT 3.0

...in which case, SPF will *always* fail on an internal email and  
this rule will always fail. DMARC can still pass with e.g. an SPF  
failure if DKIM passes - why is this an "OR"?


negated or: if either SPF or DKIM passes, the KAM_DMARC_REJECT won't
hit, because it means DMARC pass.


Thank you. I hate logical booleans lol.



I am not sure how exactly does SPF match:

header   SPF_PASS eval:check_for_spf_pass()

I'm not sure SPF should hit for locally submitted e-mail.


See above - it can't.



however, putting exemption of local mail to KAM_DMARC_REJECT could help us
to accept locally submitted mail.


Surely this has to be the fix... if an email has ONLY internal IPs,  
then DMARC assessment is irrelevant.



- End message from Matus UHLAR - fantomas  -



--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

I'd say that a proper solution would be to DKIM-sign mail before it's
spam-scanned.


On 19.04.21 19:39, Simon Wilson wrote:

Good point. If DKIM is signed it should pass DMARC, even if SPF fails.

Amavisd handles both pieces, including DKIM signing... from looking at 
the headers it looks like Amavisd is spam scanning it first *then* 
DKIM signing it. I will post to the amavisd mailing list on that 
question...


DKIM-signing locally submitted mail prior to spam scanning would help us
here (and amavis is supposed to know local domains, unlike SA)

It's not applicable for non-DKIM domains, which still can SPF pass and
therefore DMARC pass.


but, the rule could apparently avoid locally-originated mail
(would help for non-DKIM domains).

meta KAM_DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) && 
__KAM_DMARC_POLICY_REJECT


maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?


Am I reading the rule correctly that EITHER a fail DKIM or SPF will 
cause this to trip?


 meta KAM_DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) && 
__KAM_DMARC_POLICY_REJECT
 describe KAM_DMARC_REJECT DKIM has Failed or SPF has failed on the 
message and the domain has a DMARC reject policy

 scoreKAM_DMARC_REJECT 3.0

...in which case, SPF will *always* fail on an internal email and this 
rule will always fail. DMARC can still pass with e.g. an SPF failure 
if DKIM passes - why is this an "OR"?


negated or: if either SPF or DKIM passes, the KAM_DMARC_REJECT won't
hit, because it means DMARC pass.

I am not sure how exactly does SPF match:

header   SPF_PASS eval:check_for_spf_pass()

I'm not sure SPF should hit for locally submitted e-mail.

however, putting exemption of local mail to KAM_DMARC_REJECT could help us
to accept locally submitted mail.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

On 19.04.21 16:36, Simon Wilson wrote:

- I'm running KAM rules in Spamassassin
- Postfix port 587-submitted email is sent to Amavisd (as a  
content_filter) on port 10026 (tagged as ORIGINATING/MYNETS) and is  
spam-checked and DKIM-signed on its way out the door, sent back to  
Postfix at port 10025 for final delivery

- my domain has DMARC p=reject

If the final delivery is a local address, I'm getting some  
in-theory valid but in practicality invalid Spamassassin scores...  
e.g. SA is tagging those emails with KAM_DMARC_REJECT - as DMARC  
fails (correctly). The sending and receiving IPs are all internal...


Not sure if this is more an Amavis question actually, but how  
should I configure SA to not run or assess tests which make no  
sense on OUTBOUND emails - e.g. SPF, DKIM, DMARC?


I'd say that a proper solution would be to DKIM-sign mail before it's
spam-scanned.


Good point. If DKIM is signed it should pass DMARC, even if SPF fails.

Amavisd handles both pieces, including DKIM signing... from looking at  
the headers it looks like Amavisd is spam scanning it first *then*  
DKIM signing it. I will post to the amavisd mailing list on that  
question...


Example headers:

Return-Path: 
Received: from mail.simonandkate.net ([unix socket])
 by emp87.simonandkate.lan (Cyrus 3.0.7-19.el8 Fedora) with LMTPA;
 Mon, 19 Apr 2021 15:48:49 +1000
X-Cyrus-Session-Id: cyrus-1024276-1618811329-2-17461079309210778615
X-Sieve: CMU Sieve 3.0
Received: from localhost (localhost [127.0.0.1])
by mail.simonandkate.net (Postfix) with ESMTP id 46BF6805DD
for ; Mon, 19 Apr 2021 15:48:49 +1000 (AEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
simonandkate.net; h=mime-version:content-type:content-type
:reply-to:subject:subject:from:from:message-id:date:date
:received:received:received; s=default; t=1618811327; bh=Wu3ZcGt
h8o1YW+OPWu58wegp/fZmc1B+FDiux/qcXUU=; b=FuKqNJCT9CmySXiSILqBUmu
73a9tQ5a61LS/IYAZvbQIhnigw/Jb0Vq1YGqHVUplpNxpMIZnPNi+/xJN6QcJ+5k
1TQ5JV0sfNX7r58TyuiNnGkv1eFO9jRBWPpBkkrbxB4wPRe6YNPaxqFsnyFJE/Hm
nhWnxIORis0a2Z04UVuA=
X-Virus-Scanned: amavisd-new at mail.local
X-Spam-Flag: NO
X-Spam-Score: 1.911
X-Spam-Level: *
X-Spam-Status: No, score=1.911 tagged_above=-999 required=6.2
tests=[ALL_TRUSTED=-1.5, BAYES_50=0.8, DCC_REPUT_00_12=-0.4,
HTML_MESSAGE=0.001, KAM_DMARC_REJECT=3, KAM_DMARC_STATUS=0.01]
autolearn=no autolearn_force=no
Received: from mail.simonandkate.net ([127.0.0.1])
by localhost (amavis.simonandkate.net [127.0.0.1]) (amavisd-new, port 
10026)
with LMTP id NNQ0S1bHSMav for ;
Mon, 19 Apr 2021 15:48:47 +1000 (AEST)
Received: from emp86.simonandkate.lan (emp86.simonandkate.lan [192.168.1.245])
by mail.simonandkate.net (Postfix) with ESMTPSA id 089FB7B4F3
for ; Mon, 19 Apr 2021 15:48:47 +1000 (AEST)
Received: from ryzen.simonandkate.lan (ryzen.simonandkate.lan [192.168.1.1])
 by mail.simonandkate.net (Horde Framework) with HTTPS; Mon, 19 Apr 2021
 15:48:47 +1000
Date: Mon, 19 Apr 2021 15:48:47 +1000
Message-ID:  
<20210419154847.horde.1o3u94p-v2fwwnsdw38_...@mail.simonandkate.net>

From: Simon Wilson 
To: si...@simonandkate.net



but, the rule could apparently avoid locally-originated mail
(would help for non-DKIM domains).

meta KAM_DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) &&  
__KAM_DMARC_POLICY_REJECT


maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?



Am I reading the rule correctly that EITHER a fail DKIM or SPF will  
cause this to trip?


  meta KAM_DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) &&  
__KAM_DMARC_POLICY_REJECT
  describe KAM_DMARC_REJECT DKIM has Failed or SPF has failed on the  
message and the domain has a DMARC reject policy

  scoreKAM_DMARC_REJECT 3.0

...in which case, SPF will *always* fail on an internal email and this  
rule will always fail. DMARC can still pass with e.g. an SPF failure  
if DKIM passes - why is this an "OR"?






What am I trying to achieve? - I've had a compromised user account  
in the past send out spam, so I scan outbound email, with spam  
notices to postmaster (me). I want that outbound scanning to be  
sensible - only run spam tests which make sense at that point of  
the process.


while SA is not very good at scanning outgoing mail, I believe this is still
a good idea.

I've also noticed that Bayes is really struggling to learn  
local-->local emails, with consistently BAYES_20 or BAYES_50  
results. sa-learn advises tokens learned, but it still seems to  
struggle with these. Other than that my Bayes is excellent, very  
effective and accurate.


Any advice would be appreciated.



- End message from Matus UHLAR - fantomas  -



--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

On 19.04.21 16:36, Simon Wilson wrote:

- I'm running KAM rules in Spamassassin
- Postfix port 587-submitted email is sent to Amavisd (as a 
content_filter) on port 10026 (tagged as ORIGINATING/MYNETS) and is 
spam-checked and DKIM-signed on its way out the door, sent back to 
Postfix at port 10025 for final delivery

- my domain has DMARC p=reject

If the final delivery is a local address, I'm getting some in-theory 
valid but in practicality invalid Spamassassin scores... e.g. SA is 
tagging those emails with KAM_DMARC_REJECT - as DMARC fails 
(correctly). The sending and receiving IPs are all internal...


Not sure if this is more an Amavis question actually, but how should I 
configure SA to not run or assess tests which make no sense on 
OUTBOUND emails - e.g. SPF, DKIM, DMARC?


I'd say that a proper solution would be to DKIM-sign mail before it's
spam-scanned.

but, the rule could apparently avoid locally-originated mail
(would help for non-DKIM domains).

meta KAM_DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) && 
__KAM_DMARC_POLICY_REJECT

maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?


What am I trying to achieve? - I've had a compromised user account in 
the past send out spam, so I scan outbound email, with spam notices to 
postmaster (me). I want that outbound scanning to be sensible - only 
run spam tests which make sense at that point of the process.


while SA is not very good at scanning outgoing mail, I believe this is still
a good idea.

I've also noticed that Bayes is really struggling to learn 
local-->local emails, with consistently BAYES_20 or BAYES_50 results. 
sa-learn advises tokens learned, but it still seems to struggle with 
these. Other than that my Bayes is excellent, very effective and 
accurate.


Any advice would be appreciated.



--
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.
Depression is merely anger without enthusiasm.

Re: Senderscore

[Michael Grant]

On Mon, Apr 19, 2021 at 02:04:55PM +1000, Simon Wilson wrote:
> Spamassassin on my mail server uses a local dedicated caching DNS server,
> and it is only service which uses it (it's specified in local.cf).
> 
> The last 3 days I have logged about 500 failed DNS query errors to
> senderscore.com, e.g.:
> 
> 19-Apr-2021 13:28:01.367 query-errors: info: client @0x7f31c334a9a0
> 127.0.0.1#53689 (214.48.240.54.bl.score.senderscore.com): query failed
> (SERVFAIL) for 214.48.240.54.bl.score.senderscore.com/IN/A at
> ../../../bin/named/query.c:9385
> 
> ...where in the month prior there were about 10 failures logged in total.
> It's failing on what looks like every inbound email.
> 
> From what I can see it's a genuine blocklist lookup by SA...
> (RCVD_IN_RP_RNBL in 20_dnsbl_tests.cf) but the error rate is strange.
> 
> Am I the only one with high volume of lookup errors from that bl? :-) or do
> I need to be looking for an issue locally...

I am also interested in finding some sender reputation list like this.
I also had a similar experience trying to get senderscore to work.  I
picked up the phone and called them a few weeks ago.

I think initially senderscore's goal was as you (and I) thought, to
score senders such that bad senders could be blocked.  But that's not
what they do now.  What they do now is enable marketeers to get into
people's inboxes by telling the marketeers' what *their* score is
relative to the person or group they are targeting.  It's your
sendsender score, not the other way around.

I am still looking for a sender reputation list, if anyone has
recommendations, please share!

Michael Grant


signature.asc
Description: PGP signature

KAM_DMARC_REJECT on internal emails

[Simon Wilson]

Hi list,

- I'm running KAM rules in Spamassassin
- Postfix port 587-submitted email is sent to Amavisd (as a  
content_filter) on port 10026 (tagged as ORIGINATING/MYNETS) and is  
spam-checked and DKIM-signed on its way out the door, sent back to  
Postfix at port 10025 for final delivery

- my domain has DMARC p=reject

If the final delivery is a local address, I'm getting some in-theory  
valid but in practicality invalid Spamassassin scores... e.g. SA is  
tagging those emails with KAM_DMARC_REJECT - as DMARC fails  
(correctly). The sending and receiving IPs are all internal...


Not sure if this is more an Amavis question actually, but how should I  
configure SA to not run or assess tests which make no sense on  
OUTBOUND emails - e.g. SPF, DKIM, DMARC?


What am I trying to achieve? - I've had a compromised user account in  
the past send out spam, so I scan outbound email, with spam notices to  
postmaster (me). I want that outbound scanning to be sensible - only  
run spam tests which make sense at that point of the process.


I've also noticed that Bayes is really struggling to learn  
local-->local emails, with consistently BAYES_20 or BAYES_50 results.  
sa-learn advises tokens learned, but it still seems to struggle with  
these. Other than that my Bayes is excellent, very effective and  
accurate.


Any advice would be appreciated.

Simon.



--
Simon Wilson
M: 0400 12 11 16