On 7/5/19 9:55 AM, Bill Cole wrote: > On 5 Jul 2019, at 10:30, David Jones wrote: > >> On 7/5/19 9:09 AM, Bill Cole wrote: >>> On 5 Jul 2019, at 9:37, David Jones wrote: >>> >> >> I believe the only change would be the Relay-Countries value would have >> country codes in it. > > Yes, which it shouldn't. > > It may sound weird, but it is true that I work with 2 mostly unrelated > mail systems where mail comes in via MSAs whose authentication is > trustworthy from end-users who live and/or travel in places that send > those systems very little legitimate mail via untrusted/unauthenticated > sources. >
This could be handled pretty easily with a local meta rule if one wanted to subtract points for a subset of senders that also hit untrusted country codes to offset the additional score from that country hit. Those are mail servers that you actually manage so are they in the internal_networks? This proposal is only intended to change the way trusted_networks are handled. It seems like the internal_networks and trusted_networks are being used for two different purposes that don't completely overlap. 1. Trusted to not forge the Received or X-Originating-IP headers. 2. Both make up the ALL_TRUSTED rule hit and include the authenticated ESMTPA which can include spam from a compromised account. My servers are my problem to detect and handle compromised accounts. I can control these with local SA rules because I have many options at my disposal. For example, using swatch on my own logs to trigger country code lookups to detect the same user logging in from two different untrusted countries within X minutes which would be unlikely. Perhaps we need something added like a 3rd option like boundary_networks? internal_networks = in our admin control and won't forge headers trusted_networks = trust to not forge headers (no change) boundary_networks = works just like trusted_networks but X-Relay-Countries will fire. -- David Jones
