Mailing List Archive

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, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.

> 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: <simon@simonandkate.net>
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 <simon@mail.local>; 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 <simon@mail.local>;
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 <simon@simonandkate.net>; 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_cPJ@mail.simonandkate.net>
From: Simon Wilson <simon@simonandkate.net>
To: simon@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
score KAM_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 <uhlar@fantomas.sk> -----



--
Simon Wilson
M: 0400 12 11 16

>>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
> score KAM_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, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.

>>> 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
>> score KAM_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 <uhlar@fantomas.sk> -----



--
Simon Wilson
M: 0400 12 11 16

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.

----- Message from RW <rwmaillists@googlemail.com> ---------
Date: Mon, 19 Apr 2021 12:47:02 +0100
From: RW <rwmaillists@googlemail.com>
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

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

>> 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 <me@junc.eu> -----





--
Simon Wilson
M: 0400 12 11 16

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

>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, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

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

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

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.

>>>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, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states.

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

>>>>>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, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Due to unexpected conditions Windows 2000 will be released
in first quarter of year 1901

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

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

>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, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.

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.

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.

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: <root@skinnyclam.scconsult.com>
Received: from skinnyclam.scconsult.com (skinnyclam.scconsult.com
[192.168.254.125])
by toaster.scconsult.com (Postfix) with ESMTP id 4FP7Tb0wWWz5q7dl
for <bill@scconsult.com>; 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 <bill@scconsult.com>; 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=root@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=root@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=root@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=root@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

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.

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

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

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

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.

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

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 KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org pgpk -a jhardin@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

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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

----- Message from Henrik K <hege@hege.li> ---------
Date: Mon, 19 Apr 2021 17:11:41 +0300
From: Henrik K <hege@hege.li>
Reply-To: users@spamassassin.apache.org
Subject: Re: KAM_DMARC_REJECT on internal emails
To: users@spamassassin.apache.org


> 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.

Well this thread kinda developed a life of its own... lol...

Anyhoo... until the ALL_INTERNAL question is sorted, how do I disable
an "askdns" rule from running so it is not making unnecessary DNS
calls? I have for now put this in local.cf:

score KAM_DMARC_STATUS 0.0
score KAM_DMARC_REJECT 0.0
score KAM_DMARC_QUARANTINE 0.0
score KAM_DMARC_NONE 0.0

so it disables the meta rules... but how to stop the askdns queries,
e.g. in KAM.cf:

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

rather than change the channel distributed KAM.cf, what needs to go in
local.cf to tell that not to run? *CAN* it be disabled from local.cf,
or can it only be done by commenting out the entry in KAM.cf?

Simon.

--
Simon Wilson
M: 0400 12 11 16

>> >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.

>On Mon, 19 Apr 2021 19:03:55 +0200
>Matus UHLAR - fantomas wrote:
>> 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.

On 19.04.21 18:19, RW wrote:
>__LAST_EXTERNAL_RELAY_NO_AUTH will hit if an email arrived in the
>internal network from external-trusted.

that should be it, DKIM should be checked at internal network border, so it
should be checked even when receiving mail from trusted (but not internal)
hosts.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)

>>>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.

>On 19 Apr 2021, at 13:03, Matus UHLAR - fantomas wrote:
>>why not?

On 19.04.21 13:20, Bill Cole wrote:
>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.

OK, this how I understand it:

__LAST_EXTERNAL_RELAY_NO_AUTH

- message received from external (by internal) network unauthenticated
- incoming message
- check SPF/DKIM/DMARC

!__LAST_EXTERNAL_RELAY_NO_AUTH

- message received from external (by internal) network authenticated
- locally generated/outgoing message
- don't check SPF/DKIM/DMARC, may DKIM-sign

>e.g., these received headers:
>
> Return-Path: <root@skinnyclam.scconsult.com>
> Received: from skinnyclam.scconsult.com (skinnyclam.scconsult.com
>[192.168.254.125])
> by toaster.scconsult.com (Postfix) with ESMTP id 4FP7Tb0wWWz5q7dl
> for <bill@scconsult.com>; 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 <bill@scconsult.com>; 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=root@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=root@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=root@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=root@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:


this should be the correct case above - this is mail created in your
network, you chould not check, but sign it instead.



--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler

>On 19 Apr 2021, at 21:28, John Hardin wrote:
>>...so:
>>
>> header ALL_INTERNAL X-Spam-Relays-External =~ /^$/
>>
>>?

On 19.04.21 22:15, Bill Cole wrote:
>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

afik NO_RELAYS hits when mail was locally generated, which means, so you need
at least one relay, otherwise it won't hit.

Are you sure you need it this way?

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows. -- Matthew D. Fuller

>> 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
>

Hi Benny,

The original issue was OUTbound all-internal email. You mentioned
milters whitelisting 127.0.0.1 which as my milters only run on INbound
is irrelevant to the original issue (none of my milters run on
internal-->internal email). My comment on fetchmail was to point out
one example of where I change milters to *not* ignore localhost: you
cannot assume milters *always* ignore localhost just because they do
by default. And I do not have a problem with fetchmail to solve - it
works well, configured to drop to my smtphost where milters *do*
process it as inbound email, even though it is seen as being from
localhost (the fetchmail daemon smtphost drops it to a specific
postfix instance).

Anyway, back to OUTBOUND internal-->internal :)

When SA runs in this scenario email has not been DKIM signed, SPF is
irrelevant, and the email has never left my perimeter - a DMARC
evaluation should NOT be run. It looks like there are some good ideas
on how to resolve that, for which I am grateful.



FWIW...
Whilst I can see the value of the KAM DMARC rules for an "out of the
box" install of SA, I will likely leave them disabled on ALL email: I
have a robust inbound milter setup which adds sequentially trusted
headers for SPF, DKIM, ARC and DMARC.

My preference is for SA to use \existing trusted headers/ to base
DKIM, SPF, ARC, DMARC score decisions on - *NOT* to run additional DNS
lookups to do its own when they have already been done (even though
likely nameserver-cached).

I already do this with DMARC, which SA does not do DNS-checking tests
for (out of the box, i.e. without KAM rules). I have custom rules in
local.cf which use the headers provided by OpenDMARC:

e.g.
header DMARC_FAIL_REJECT Authentication-Results =~
/mail\.simonandkate\.net; dmarc=fail \(p=reject/
describe DMARC_FAIL_REJECT DMARC check failed (p=reject)
score DMARC_FAIL_REJECT 6.0

That works fine, and has the bonus of only running when I expect it to
- which is when I have ensured the relevant milters have run and added
trusted headers on inbound email.

Simon.

--
Simon Wilson
M: 0400 12 11 16

On 2021-04-20 13:48, Matus UHLAR - fantomas wrote:
>> On 19 Apr 2021, at 21:28, John Hardin wrote:
>>> ...so:
>>>
>>> header ALL_INTERNAL X-Spam-Relays-External =~ /^$/
>>>
>>> ?
>
> On 19.04.21 22:15, Bill Cole wrote:
>> 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
>
> afik NO_RELAYS hits when mail was locally generated, which means, so
> you need
> at least one relay, otherwise it won't hit.
>
> Are you sure you need it this way?

!NO_RELAYS is external ip since NO_RELAYS is internal_networks

this is so cool that Bill created another rule for ALL_EXTERNAL when
NO_RELAYS exists :/

please fokus on DKIM signed mails is LOCAL domains or not

KAM cant help knowing what is local or not, we all wait for spamassassin
4.x.x where this mess is solved by no need for any rules waste anymore

Bill have this in mind when AuthRes doing this on 4.x.x then KAM rule
will be not needed or atleast change for 4.x.x usage

hope the best for the future of spamassassin

> > On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote:
>
> rather than change the channel distributed KAM.cf, what needs to go in
> local.cf to tell that not to run? *CAN* it be disabled from local.cf, or can
> it only be done by commenting out the entry in KAM.cf?

It would not make any sense to not be able to override things. Or edit a
channel file which would later be overwritten? Of course you can disable it
in local.cf:

score __KAM_DMARC_POLICY_REJECT 0

On 2021-04-20 14:21, Simon Wilson wrote:

> header DMARC_FAIL_REJECT Authentication-Results =~
> /mail\.simonandkate\.net; dmarc=fail \(p=reject/
> describe DMARC_FAIL_REJECT DMARC check failed (p=reject)
> score DMARC_FAIL_REJECT 6.0
>
> That works fine,

this rule is DMARC testing in OUTbound mail, dont do this :)

the rule is fine for INbound mail, IF you use opendmarc before
spamassassin milter, there is no garenti that spamassassin see opendmarc
results in that chains of trustness

its safe to remove all AR headers before doing own milters that add
local testing and trusted headers, AR headers is not DKIM signed by a
good reason :=)

> and has the bonus of only running when I expect it to
> - which is when I have ensured the relevant milters have run and
> added trusted headers on inbound email.

irrelevant since the rule in spamassassin is still used in OUTbound and
INbound, it will give false possitive testing this in spamassassin, work
around could be to have spamd for inbound,and spamd for outbound, but
this needs new rules for outbound :=)

i remember KAM sayed, the possible to do anything in Framework is
stable, its just rules that is still waiting for spamassassin 4.x.x

when you post problems here its a hope KAM listen on it, and will
possible change the problem

all the best, YMMV

>
> Simon.

>> > On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote:
>>
>> rather than change the channel distributed KAM.cf, what needs to go in
>> local.cf to tell that not to run? *CAN* it be disabled from local.cf, or can
>> it only be done by commenting out the entry in KAM.cf?
>
> It would not make any sense to not be able to override things. Or edit a
> channel file which would later be overwritten? Of course you can disable it
> in local.cf:
>
> score __KAM_DMARC_POLICY_REJECT 0

Thanks Henrik -

So KAM.cf's

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

is prevented from running its DNS query by setting in local.cf:

score __KAM_DMARC_POLICY_REJECT 0

That is what I wanted to understand :) thanks.

So the best way to disable the KAM DMARC rules is not to set score 0
on the metas, but set score 0 on the askdns rules:

score __KAM_DMARC_POLICY_REJECT 0
score __KAM_DMARC_POLICY_QUAR 0
score __KAM_DMARC_POLICY_NONE 0
score __KAM_DMARC_POLICY_DKIM_STRICT 0

... as then the metas will never pass.


--
Simon Wilson
M: 0400 12 11 16

On 2021-04-20 14:35, Henrik K wrote:
>> > On Mon, Apr 19, 2021 at 10:05:21PM +1000, Simon Wilson wrote:
>>
>> rather than change the channel distributed KAM.cf, what needs to go in
>> local.cf to tell that not to run? *CAN* it be disabled from local.cf,
>> or can
>> it only be done by commenting out the entry in KAM.cf?
>
> It would not make any sense to not be able to override things. Or edit
> a
> channel file which would later be overwritten? Of course you can
> disable it
> in local.cf:
>
> score __KAM_DMARC_POLICY_REJECT 0

i just say it does not solve the real problem

it possible already solved in spamassassin 4

is it time for RFE with running spamd for indbound and another spamd for
outbound ?

Framework is still missing for this

On 2021-04-20 14:48, Simon Wilson wrote:

> score __KAM_DMARC_POLICY_REJECT 0
> score __KAM_DMARC_POLICY_QUAR 0
> score __KAM_DMARC_POLICY_NONE 0
> score __KAM_DMARC_POLICY_DKIM_STRICT 0
>
> ... as then the metas will never pass.

any solutions creates another problem

>> header DMARC_FAIL_REJECT Authentication-Results =~
>> /mail\.simonandkate\.net; dmarc=fail \(p=reject/
>> describe DMARC_FAIL_REJECT DMARC check failed (p=reject)
>> score DMARC_FAIL_REJECT 6.0
>>
>> That works fine,
>
> this rule is DMARC testing in OUTbound mail, dont do this :)

***No it is not DMARC testing in OUTbound mail*** (not shouting, just
stressing this point)

Read my message again please :)
I have said a few times I do *not* run milters on outbound email, so
the header that rule tests for *does not exist on outbound email*, and
so the custom DMARC rule does not trigger on outbound email. It DOES
trigger on INbound emails, which is correct.


> the rule is fine for INbound mail, IF you use opendmarc before
> spamassassin milter, there is no garenti that spamassassin see
> opendmarc results in that chains of trustness
>
> its safe to remove all AR headers before doing own milters that add
> local testing and trusted headers, AR headers is not DKIM signed by
> a good reason :=)
>
>> and has the bonus of only running when I expect it to
>> - which is when I have ensured the relevant milters have run and
>> added trusted headers on inbound email.
>
> irrelevant since the rule in spamassassin is still used in OUTbound
> and INbound, it will give false possitive testing this in
> spamassassin, work around could be to have spamd for inbound,and
> spamd for outbound, but this needs new rules for outbound :=)

Sorry, you have not understood what I have written.

I will try and be clearer:

- OpenDMARC only runs on inbound email (controlled as a milter only on
port 25 inbound Postfix)
- When OpenDMARC runs it adds an Authentication-Results header with a
trusted Authserv-ID
- Only when that header exists does the rule trigger in Spamassassin,
i.e. THE RULE ONLY TRIGGERS ON INBOUND



--
Simon Wilson
M: 0400 12 11 16

On 20 Apr 2021, at 7:48, Matus UHLAR - fantomas wrote:

>> On 19 Apr 2021, at 21:28, John Hardin wrote:
>>> ...so:
>>>
>>> header ALL_INTERNAL X-Spam-Relays-External =~ /^$/
>>>
>>> ?
>
> On 19.04.21 22:15, Bill Cole wrote:
>> 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
>
> afik NO_RELAYS hits when mail was locally generated, which means, so
> you need
> at least one relay, otherwise it won't hit.
>
> Are you sure you need it this way?

Sure? I'm rarely sure about anything...

It was suggested to me off-list and I think it makes sense from a broad
view to have non-overlapping full coverage of the possibilities and
semantic consistency across "ALL_TRUSTED" and "ALL_INTERNAL" in
asserting that "ALL" is non-zero.

However, it does make sense in this case to exclude __NO_EXTERNALS from
DMARC checking rather than ALL_INTERNAL. I'm undecided on whether either
actually needs to be a scored rule.

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

On Mon, 19 Apr 2021 20:40:58 -0400
Bill Cole wrote:

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

> 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

Anything that enters through through the remote trusted network and hits
ALL_TRUSTED will almost certainly pass whatever authentication
mechanism are set-up for the domain.

The difference between ALL_TRUSTED and ALL_INTERNAL will likely be
small. There are minor advantages either way.

>On Mon, 19 Apr 2021 20:40:58 -0400
>Bill Cole wrote:
>> 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

On 21.04.21 00:11, RW wrote:
>Anything that enters through through the remote trusted network and hits
>ALL_TRUSTED will almost certainly pass whatever authentication
>mechanism are set-up for the domain.
>
>The difference between ALL_TRUSTED and ALL_INTERNAL will likely be
>small. There are minor advantages either way.

the diference would be, ALL_TRUSTED covers mail from trusted, but not
internal hosts, that are trusted not to fake headers, but still may
send spam.

Such mail should imho still be checked for DMARC.

The ALL_INTERNAL, or better the NO_RELAYS as Benny pointed out should only
hit on mail generated in internal network.

The !__LAST_EXTERNAL_RELAY_NO_AUTH I proposed should hit on mail entered
internal network authenticated, which imho means it's an outgoing e-mail.


--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod

> On 21.04.21 00:11, RW wrote:
> >Anything that enters through through the remote trusted network and
> >hits ALL_TRUSTED will almost certainly pass whatever authentication
> >mechanism are set-up for the domain.
> >
> >The difference between ALL_TRUSTED and ALL_INTERNAL will likely be
> >small. There are minor advantages either way.
>
> the diference would be, ALL_TRUSTED covers mail from trusted, but not
> internal hosts, that are trusted not to fake headers, but still may
> send spam.

Unless a dynamic pool has been put into the trusted network, this is
about authenticated relays. Spammers gain access to third-party
accounts to pass authentication tests - not to spam with a random
domain that will fail such tests.

>> On 21.04.21 00:11, RW wrote:
>> >Anything that enters through through the remote trusted network and
>> >hits ALL_TRUSTED will almost certainly pass whatever authentication
>> >mechanism are set-up for the domain.
>> >
>> >The difference between ALL_TRUSTED and ALL_INTERNAL will likely be
>> >small. There are minor advantages either way.

>> the diference would be, ALL_TRUSTED covers mail from trusted, but not
>> internal hosts, that are trusted not to fake headers, but still may
>> send spam.

On 22.04.21 00:07, RW wrote:
>Unless a dynamic pool has been put into the trusted network,

...which is quite common at ISPs

>this is
>about authenticated relays. Spammers gain access to third-party
>accounts to pass authentication tests - not to spam with a random
>domain that will fail such tests.

still, authenticated mail is outgoing mail, not incoming mail, and you
should not expect it to be DKIM-signed, you have to dkim-sign it.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]

On 2021-04-22 14:15, Matus UHLAR - fantomas wrote:

> still, authenticated mail is outgoing mail, not incoming mail, and you
> should not expect it to be DKIM-signed, you have to dkim-sign it.

dont dkim sign if mails is not localy smtp auth senders / clients

forwarding mail servers should only ARC seal mails with openARC or
MAIL::DKIM with supports ARC already

but for this to work we all waiting for openDMARC and spamassassin to
verify ARC sealing

see dovecot maillist where it works as an good example on what to do, i
say it again dont dkim sign mails that is not sasl auth on port 465 /
587

please respect ATPS in dkim if still want to do something

t-online.de dkim signs with 3dr party dkim, and thay soon will see loose
on custommers

back to subject, should not hit on NO_RELAYS

On Thu, 22 Apr 2021 14:15:07 +0200
Matus UHLAR - fantomas wrote:

> >> On 21.04.21 00:11, RW wrote:
> >> >Anything that enters through through the remote trusted network
> >> >and hits ALL_TRUSTED will almost certainly pass whatever
> >> >authentication mechanism are set-up for the domain.
> >> >
> >> >The difference between ALL_TRUSTED and ALL_INTERNAL will likely be
> >> >small. There are minor advantages either way.
>
> >> the diference would be, ALL_TRUSTED covers mail from trusted, but
> >> not internal hosts, that are trusted not to fake headers, but
> >> still may send spam.
>
> On 22.04.21 00:07, RW wrote:
> >Unless a dynamic pool has been put into the trusted network,
>
> ...which is quite common at ISPs

I was thinking more of third-party pools. It's better to use
msa_networks anyway, since that prevents pool addresses being seen as
trusted when they aren't going through the submission server.

>
> >this is
> >about authenticated relays. Spammers gain access to third-party
> >accounts to pass authentication tests - not to spam with a random
> >domain that will fail such tests.
>
> still, authenticated mail is outgoing mail, not incoming mail, and you
> should not expect it to be DKIM-signed, you have to dkim-sign it.

I was referring to the case where a spammer is using an account in the
wider trusted network to send spam to the internal network. In that
case it will very likely pass any authentication.

KAM_DMARC_REJECT is not a very good rule anyway. It can let-off DMARC
fails by not checking for any alignment on SPF_PASS. OTOH if SPF fails
it will hit legitimate mail through the lack of support for relaxed DKIM
alignment. This is on top of the fact that DMARC has changed the
behaviour of spammers, removing much of the benefit of even an accurate
test, whilst leaving all the FP risk.

I wont be using it, but if I were to, my preference would be to give the
trusted network the benefit of the doubt. And as I said I don't think
much spam from the trusted network is going to fail DMARC anyway.

>> >> On 21.04.21 00:11, RW wrote:
>> >> >Anything that enters through through the remote trusted network
>> >> >and hits ALL_TRUSTED will almost certainly pass whatever
>> >> >authentication mechanism are set-up for the domain.
>> >> >
>> >> >The difference between ALL_TRUSTED and ALL_INTERNAL will likely be
>> >> >small. There are minor advantages either way.
>>
>> >> the diference would be, ALL_TRUSTED covers mail from trusted, but
>> >> not internal hosts, that are trusted not to fake headers, but
>> >> still may send spam.
>>
>> On 22.04.21 00:07, RW wrote:
>> >Unless a dynamic pool has been put into the trusted network,

>On Thu, 22 Apr 2021 14:15:07 +0200
>Matus UHLAR - fantomas wrote:
>> ...which is quite common at ISPs

On 23.04.21 22:35, RW wrote:
>I was thinking more of third-party pools. It's better to use
>msa_networks anyway, since that prevents pool addresses being seen as
>trusted when they aren't going through the submission server.

All relays found in the message headers after the MSA relay will take on
the same trusted and internal classifcations as the MSA relay itself, as
defined by your trusted_networks and internal_networks configuration.

For example, if the MSA relay is trusted and internal so will all of the
relays that precede it.

I understand that as only MSAs should be put into msa_networks, not other
addresses.

I still think that DMARC check should be done on edge of internal network,
not anywhere behind it.


>> >this is
>> >about authenticated relays. Spammers gain access to third-party
>> >accounts to pass authentication tests - not to spam with a random
>> >domain that will fail such tests.
>>
>> still, authenticated mail is outgoing mail, not incoming mail, and you
>> should not expect it to be DKIM-signed, you have to dkim-sign it.
>
>I was referring to the case where a spammer is using an account in the
>wider trusted network to send spam to the internal network. In that
>case it will very likely pass any authentication.

that's correct, however the problem arises when someone trusted sends mail
from local domain, where we don't expect mail to be DKIM-signed (yet).

this should better be controlled at different level, e.g. validating
correct from address at MTA level, comparing address with local domains
(SA 3.4 doesn't know local domains)...

>KAM_DMARC_REJECT is not a very good rule anyway. It can let-off DMARC
>fails by not checking for any alignment on SPF_PASS. OTOH if SPF fails
>it will hit legitimate mail through the lack of support for relaxed DKIM
>alignment. This is on top of the fact that DMARC has changed the
>behaviour of spammers, removing much of the benefit of even an accurate
>test, whilst leaving all the FP risk.

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

so, instead of plain SPF_PASS we needed to make sure that envelope from
matches header from, for DKIM to pass.

something like HEADER_FROM_DIFFERENT_DOMAINS, but that one compares parent
domains.

>I wont be using it, but if I were to, my preference would be to give the
>trusted network the benefit of the doubt. And as I said I don't think
>much spam from the trusted network is going to fail DMARC anyway.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!

On Sat, 24 Apr 2021 13:32:09 +0200
Matus UHLAR - fantomas wrote:
addresses.
>
> I still think that DMARC check should be done on edge of internal
> network, not anywhere behind it.

It's not about that, it's about whether or not you apply it to

<Authenticated-client> -> <trusted third-party mail system> ->
<MX server in internal networks>


"&& !ALL_INTERNAL" does allow the slightly unreliable DMARC fail test to
run on that mail and "&& !ALL_TRUSTED" doesn't.

IMO the former wont catch much extra spam because the point of spamming
that way is to pick-up DKIM and SPF passes. So it's mostly extra risk.