In message <pine.neb.4.64.1601151625480.18...@pokey.whooppee.com>
Paul Goyette writes:
>  
>  
> I'm having a little bit of a problem with my configuration...  :)
>  
> I have followed all of the how-to docs on getting things set up, and
> everything works fine when an Email client connects to my primary mail
> server.  The postfix rules get triggered and the dspam filter gets
> invoked.
>  
> The problem occurs when a "foreign" client uses my backup MX relay
> machine.  The backup-MX 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.

Hi Paul,

I'm not the expert that some on this list are ... but here goes.

Take a look at http://www.postfix.org/SMTPD_ACCESS_README.html#danger
and see if it seems familiar.  If so the answer might be in the use of
smtpd_relay_restrictions rather than smtpd_recipient_restrictions as
long as you are running postfix >= 2.10.

If not, then you might be able to move reject_unauth_destination up in
the list.

> Is there a more appropriate way to trigger the dspam filter, so that
> messages that are relayed by the backup MX server get filtered, BUT
> messages that _originate_on_ the backup MX server are not filtered?

How about http://www.postfix.org/SMTPD_PROXY_README.html ?

> Stated another way, there are 3 classes of messages involved:
>  
> 1. Messages that originate on either of the MX servers.
> 2. Messages that originate externally, and are initially sent to the
>     backup-MX machine;  the backup-MX does the usual store-&-forward
>     to get messages to the primary-MX machine.
> 3. Messages that originate externally and are sent directly to the
>     primary-MX machine.
>  
> Class 1 should _not_ be processed by dspam, and currently behaving
>          as desired
> Class 2 _should_ be processed, but currently is not being processed
> Class 3 _should_ be processed, and is currently behaving as desired.
>  
> Config details are available - just ask for them!

If that didn't help and no one else responds, then maybe go for it.

> +------------------+--------------------------+------------------------+
> | 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 |
> +------------------+--------------------------+------------------------+

Curtis

Reply via email to