On 7/4/19 6:35 PM, Bill Cole wrote: > On 4 Jul 2019, at 16:59, David Jones wrote: > >> It seems like authenticated mail submission should only apply to >> internal_networks and not extend out to the trusted_networks. > > No. See https://wiki.apache.org/spamassassin/DynablockIssues. > > In short: if you don't trust the authentication of your > trusted_networks, you will end up rejecting their legitimately > authenticated users for being on PBL-like DNSBLs. > > Arguably the trusted/internal/msa network model could use a rethink > since today we see so many cracked accounts. If you have specific > ideas other than redefining an existing client class back to a broken > former handling, I'd be interested in that discussion. > Maybe allow the RelayCountry check to happen on the msa network or the first relay?
Or something like trusted_countries that could provide a limit/boundary to the trust of trusted_networks? Compromised accounts often get abused from foreign/unusual countries. I have meta rules and DWL/DBL for emails combined with RelayCountry but these are useless in this situation. >> I trust the 96.4.165.21 mail server to not forge the Received headers >> but compromised accounts happen. >> >> Is there another way to accomplish checking the that 88.233 IP as the >> last-external without stripping off the "A" in ESMTPA at the MTA before >> SA sees it? > > Not without checking the IP of every authenticated client of > trusted_networks. I think you can do it with the '-firsttrusted' > suffix for DNSBL rules so that you could define a rule that looks for > SBL & XBL hits but not PBL hits in Zen. > I was thinking about stripping the "A" off othe ESMTPA just for this email server since I know that customer's mail flow should never have email originate from Turkey and most other countries outside of the US. I don't care so much about RBLs but the country is a big indicator of a compromised account.
