Hi, >> This originated with me trying to have a better understanding of SPF. >> check_sender_access consults $mynetworks to determine which servers >> can send mail as my domain. > > Eh? check_sender_access can only check the envelope sender address, > not a network or hostname.
Yes, thanks, I don't know why I was thinking that. >> How does this relate to entries in my SPF record for servers that may >> be sending mail to users in my domain? I would think it would be >> necessary to list them in $mynetworks, however, I don't want to >> inherit whatever other problems come with other things happening on >> those IPs. > > 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? > 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? >> 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? Maybe it could be set up as an amavisd $policy_bank to skip filtering? >> mail01.example.com local: >> site1.example.com smtp:[66.XXX.YYY.100] >> >> Is it necessary in this case to have $transport_maps as part of >> relay_domains? > > I'm going to assume these are domains you own/control, otherwise > they should never be in relay_domains. Yes, that's correct. > 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? 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. > Anyway, the default value of parent_domain_matches_subdomains > includes relay_domains, so "X.example.com" is already included by > way of "example.com". If they aren't really related subdomains, > just include them in relay_domains explicitly. It's a mail relay, so the main domain (example.com) and one of the subdomains (cs.example.com) goes to an Exchange connector, while the third is routed to a postfix/dovecot server. Thanks for being so patient with me. Alex
