On 12/10/2015 8:39 AM, Alex wrote: >> >> This is independent of SPF. The rules discussed blocks your domain >> as envelope sender except for a whitelist you have specified >> (permit_mynetworks). > > Yes, and that was part of my concern. There are includes in our SPF > record for networks that we don't control. I don't want to add these > IPs to our $mynetworks, making them trusted for all mail. Am I > understanding that correctly?
In that case, rather than using permit_mynetworks you should use a separate check_client_access that permits all the authorized IPs. Make sure to do this in smtpd_sender_restrictions so that settings here don't affect relay rules. > >> As an _alternative_, you could publish SPF records and run all your >> mail through a SPF policy, and reject (or tag) those that fail. > > We are currently publishing an SPF record for our domain. Can you > explain how to create an SPF policy? Do you mean using pypolicyd-spf? any policy service that checks SPF records. > >>> I was in the process of setting up SPF, but ran into some stability >>> problems with the pyspf application. >> >> I use SpamAssassin for SPF and DKIM verification, integrated into >> postfix via amavisd-new as a pre-queue smtpd_proxy_filter, which >> works well for my purpose. > > I'm also using spamassassin and amavisd-new, and would also prefer to > do it there. However, I believe the problem I had with doing that in > the past is the volume of mail that could be received at once, and not > being able to process it as fast as it arrives. Is that correct? That's really a separate issue. If you're already using amavisd-new with SpamAssassin, enabling SPF checks there add virtually zero extra overhead. If your filter isn't keeping up with the mail flow, then you need to use a different filtering arrangement or add more hardware. > > Maybe it could be set up as an amavisd $policy_bank to skip filtering? Yes, you could skip filtering for mail arriving from "trusted" IPs. >> While there is nothing technically wrong with using $transport_maps >> here, it's kind of like playing with fire... you're one mistake away >> from disaster. > > I don't understand. How is it dangerous? For example, you add a transport for gmail to work around some delivery problem you're having; this isn't particularly unusual. Because your relay_domains also includes $transport_maps now gmail is in your relay_domains and you become an open relay for any mail addressed to gmail. > > I believe this was set up because we have a fallback_relay set up in > master.cf. I also didn't know how else to route mail for one of our > subdomains to a postfix server responsible for that subdomain. Yes, a transport_maps entry is the correct solution for routing, but don't add $transport_maps to relay_domains. If it's necessary to share a map -- maybe for large number of domains -- it's better to use a dedicated map with an obvious name, like "relay_domains_transport" or whatever makes sense to you, and just share that one map rather than the whole $transport_maps setting. And in your particular case, you probably don't need any extra relay_domains entries because of parent_domain_matches_subdomains -- Noel Jones
