Mailing List Archive

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

something like HEADER_FROM_DIFFERENT_DOMAINS, but that one compares parent
domains.

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

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

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

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

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


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

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