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 sligh
>> 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
>> >s
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.
> >> >
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
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
> 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.
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_R
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 uns
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
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
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 pro
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 i
> 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
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, do
> > 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
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 i
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 whet
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:
describ
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
>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 wro
- 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
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 discussi
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
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
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 misunder
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
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
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
externa
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 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?
Wh
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
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 ma
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 && !(
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
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 interf
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
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
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
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 t
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 q
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 ye
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
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 m
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 modif
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", s
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
- 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
- Po
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 d
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 A
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 Am
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 1
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 1002
52 matches
Mail list logo
