Mailing List Archive

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