On 31 Mar 2019, at 2:38, Jon LaBadie wrote:
When I try to block spam from repeaters, via access.db,
firewall, ... the first thing that happens is the blocked
mail gets delivered via my MX backup host. Mail received
by this route does not seem to be checked against the
access database.
Is there something I'm not turning on to enable checks
of mail received via the MX backup host?
No, because the whole concept of "MX backup host" is antiquated and
obsolete, dating from a time when >99.9% of email was wanted and
legitimate. If you cannot replicate the edge filtering across all MX
hosts for a domain and
assure that acceptance at any MX will result in delivery to some
recipient-accessible mailbox, you should not have multiple MX hosts.
Beyond that, MTAs such as Postfix are not generally designed to examine
and parse the audit trail of Received headers added by past SMTP hops in
an attempt to figure out what happened somewhere else in the travel of a
piece of email. With the exception of the extremely limited
header_checks and body_checks features (which are INTENTIONALLY weak and
simplistic) all of the access controls in Postfix operate on the
parameters of the SMTP transaction: the connecting IP and its reverse
DNS name, HELO name, authentication and related authorizxation state,
sender address, and recipient addresses. The pure sender and recipient
access restrictions in Postfix still work with email arriving via a
backup MX but everything else about the SMTP transaction is different.
However, if you use REJECT with those restrictions you will generate
backscatter at innocent forgery victims, while using DISCARD puts you at
risk of dropping some valid wanted mail into a black hole.
You can get *some* filtering nuance for mail routed via a trusted
secondary MX from robust filtering tools like SpamAssassin that have a
logical model for such circumstances where you need to interpret and
trust what another host claims has happened to a message but to do
something more nuanced than simply rejecting or discarding messages that
the filter determines to be probable unwanted junk.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole