Re: KAM_DMARC_REJECT on internal emails

[RW]

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 

 ->  ->



"&& !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.

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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.

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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

 

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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.

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

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

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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_STRICT0

... as then the metas will never pass.


any solutions creates another problem

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

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

... as then the metas will never pass.


--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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.

Re: KAM_DMARC_REJECT on internal emails

[Henrik K]

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

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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

I understand this as:

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


On 19.04.21 12:49, Bill Cole wrote:

I cannot make SA behave that way.



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: 
	Received: from skinnyclam.scconsult.com (skinnyclam.scconsult.com 
[192.168.254.125])

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



Results in these RELAYS* assignments:

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



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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

>On 19 Apr 2021, at 11:30, Matus UHLAR - fantomas wrote:
>> I understand this as:
>>
>> if mail was received by internal relay unauthenticated, it's
>> external,

On 19.04.21 12:49, Bill Cole wrote:
>I cannot make SA behave that way.



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, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fucking windows! Bring Bill Gates! (Southpark the movie)

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

- Message from Henrik K  -
Date: Mon, 19 Apr 2021 17:11:41 +0300
From: Henrik K 
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:


scoreKAM_DMARC_STATUS 0.0
scoreKAM_DMARC_REJECT 0.0
scoreKAM_DMARC_QUARANTINE 0.0
scoreKAM_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

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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


On Mon, 19 Apr 2021, Bill Cole wrote:


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


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



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



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

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

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


&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


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


...so:

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

?


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


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

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


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

Re: KAM_DMARC_REJECT on internal emails

[John Hardin]

On Mon, 19 Apr 2021, Bill Cole wrote:


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


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



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



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

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

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


&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


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


...so:

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

?


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.org pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Our politicians should bear in mind the fact that
  the American Revolution was touched off by the then-current
  government attempting to confiscate firearms from the people.
---
 Today: the 246th anniversary of The Shot Heard 'Round The World

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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


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




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


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


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




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


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


Is that any more clear?

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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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


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

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

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

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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


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


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



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


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



See

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


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


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


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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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

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

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

See

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

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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


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


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


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

I understand this as:

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


On 19.04.21 12:49, Bill Cole wrote:

I cannot make SA behave that way.


why not?


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


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


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


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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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

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

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

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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


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

I understand this as:

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


On 19.04.21 12:49, Bill Cole wrote:

I cannot make SA behave that way.


why not?


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


e.g., these received headers:

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

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


Results in these RELAYS* assignments:

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




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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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

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


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

Re: KAM_DMARC_REJECT on internal emails

[RW]

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

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

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

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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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

I understand this as:

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


On 19.04.21 12:49, Bill Cole wrote:

I cannot make SA behave that way.


why not?

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

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

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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

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

I cannot make SA behave that way.


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

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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


I understand this as:

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

therefore, should be subject to DMARC checks.


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


hope sa wont change this

consider NO_RELAYS aswell

no new rules is needed as bill added to test rules

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


if !NO_RELAYS
 askdns 
endif

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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



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



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

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

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



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

&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


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


I understand this as:

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


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

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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


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



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



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

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

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


&& __LAST_EXTERNAL_RELAY_NO_AUTH
should do that.


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



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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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



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



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

you trust not to fake headers.


On 19.04.21 09:46, Bill Cole wrote:

A valid point.

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


&& __LAST_EXTERNAL_RELAY_NO_AUTH 

should do that. 



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

Re: KAM_DMARC_REJECT on internal emails

[Henrik K]

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

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

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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

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

run anyway?


note rulename starts with __ ?


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


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

its a waste rule if this happend

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


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


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




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


make your fetchmail use mda, problem solved


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


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

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


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


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


sometimes its needed to debug

all the best

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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

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


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


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


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

you trust not to fake headers.


A valid point.

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


ALL_INTERNAL untrusted ... :=)

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


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

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

hopefully this is clear now

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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


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


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


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

you trust not to fake headers.


A valid point.

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

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

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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


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


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

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

Re: KAM_DMARC_REJECT on internal emails

[Bill Cole]

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

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


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


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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

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

run anyway?


note rulename starts with __ ?


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





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


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




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


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


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


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


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


- End message from Benny Pedersen  -





--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[Benny Pedersen]

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


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

run anyway?


note rulename starts with __ ?


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


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


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


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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

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



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


Hi list,

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

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



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


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


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

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


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



Simon

--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[RW]

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

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

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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

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


On 19.04.21 19:39, Simon Wilson wrote:

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

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


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



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



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


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

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




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

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


maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?


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


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

scoreKAM_DMARC_REJECT 3.0

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


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


Thank you. I hate logical booleans lol.



I am not sure how exactly does SPF match:

header   SPF_PASS eval:check_for_spf_pass()

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


See above - it can't.



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


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



- End message from Matus UHLAR - fantomas  -



--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

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


On 19.04.21 19:39, Simon Wilson wrote:

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

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


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

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


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

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


maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?


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


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

 scoreKAM_DMARC_REJECT 3.0

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


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

I am not sure how exactly does SPF match:

header   SPF_PASS eval:check_for_spf_pass()

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

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

Re: KAM_DMARC_REJECT on internal emails

[Simon Wilson]

On 19.04.21 16:36, Simon Wilson wrote:

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

- my domain has DMARC p=reject

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


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


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


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

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


Example headers:

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

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



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

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


maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?



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


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

  scoreKAM_DMARC_REJECT 3.0

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






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


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

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


Any advice would be appreciated.



- End message from Matus UHLAR - fantomas  -



--
Simon Wilson
M: 0400 12 11 16

Re: KAM_DMARC_REJECT on internal emails

[Matus UHLAR - fantomas]

On 19.04.21 16:36, Simon Wilson wrote:

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

- my domain has DMARC p=reject

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


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


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

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

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

maybe __LAST_EXTERNAL_RELAY_NO_AUTH ?


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


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

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


Any advice would be appreciated.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Depression is merely anger without enthusiasm.

KAM_DMARC_REJECT on internal emails

[Simon Wilson]

Hi list,

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

- my domain has DMARC p=reject

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


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


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


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


Any advice would be appreciated.

Simon.



--
Simon Wilson
M: 0400 12 11 16