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.
