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.
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.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
