On Thu, 14 Jan 2016, Hal Murray wrote:
paul%whooppee.com@localhost said:
The problem occurs when a "foreign" client uses my backup MX relay machine.
This machine is part of my own network, so it gets included in the primary
server's $mynetworks (via 'mynetworks_style = subnet'). Unfortunately this
seems to cause my
smtpd_client_restrictions = permit_mynetworks,
check_client_access ...dspam...
to permit the message without triggering the dspam filter.
You need to duplicate the anti-spam filtering on any backup MXes. Another approach is to eliminate backup MXes. If your primary server is solid, a backup server on your own network doesn't cover any problems with the link to your ISP.
Actually, I have a good reason for using a backup-MX - the primary mail server is only reachable via IPv6. It is "hidden" behind an IPv4-only NAT box. Connectivity between the primary and backup MX machines is via an openvpn tunnel, running IPv6-over-IPv4 (the IPv6 address range is globally visibile and routable).
Note that even if your primary server did filter mail from your backup server, that just gets you into the bounce vs reject mess. If your primary server rejects it, your secondary server can either drop it or send a bounce. If you don't send the bounce, the sender of legitimate mail doesn't know that it didn't work. If you do send the bounce, and the return address was forged (which is common on spam), the bounce will go to an innocent victim. Google for backscatter or outscatter.
I'm trying to set up filtering ONLY on the primary (final destination) mail server. Any mail that gets sent to the backup-MX should be forwarded directly to the primary, with no filtering on the backup-MX.
+------------------+--------------------------+------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+------------------------+