Re: KAM_DMARC_REJECT on internal emails
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
>> 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
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
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
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
> 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
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
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
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
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
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
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
> 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
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
> > 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
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
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
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
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
>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
- 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- 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
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
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
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
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
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
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