On Mon, Apr 5, 2010 at 11:10 AM, Kris Deugau <kdeu...@vianet.ca> wrote: > Royce Williams wrote: >> >> What is the optimal configuration (local.cf or other) for an ISP's >> MSAs to prevent unauthenticated dynamic-IP customers from triggering >> dynamic tests, but still benefiting from general filtering? >> >> I was hoping for a magical 'mua_networks' option, which let me >> enumerate the IP space that my users submit from, and automatically >> exempt them from DOS_OE_TO_MX, etc., but I haven't been able to find >> anything like that. >> >> From my reading of the .conf manpage, the TrustPath page, and the >> archives (see references below), I've tentatively concluded that I >> will need to have some local rule overrides on all of my MSAs for any >> rule or meta-rule that detects dynamic-looking hostnames ... but that >> seems high-maintenance locally as well as a lot of duplicated work for >> other SA users. > > Read, read, and re-read. It's a bit tangled and confusing balancing the > various requirements but you should be able to get it right with a little > effort. > > To summarize what I've applied here: > > trusted_networks: Contains CIDR ranges for our servers. These systems are > "trusted" in that we know they will not forge Received: headers. I've added > a number of third-party systems here for various reasons. > > internal_networks: IPs or CIDR ranges for your inbound mail flow, *within > your network*. Usually equivalent to trusted_networks, but not always; > must be *entirely contained by* trusted_networks. I've included one of > Postini's IP ranges here to catch mail relayed to domains handled by Postini > that might otherwise have been blocked at the MTA level by Spamhaus' Zen. > > msa_networks: IPs of CIDR ranges for your outbound mail flow, IE systems > that accept mail from your authorized customer IP ranges. (and anywhere > else via SMTP AUTH or similar). As far as I can tell, these *may* overlap > internal_networks but if you're big enough that these settings are a > problem, they probably don't. Also a subset of trusted_networks. (FWIW, I > found overlapping this with internal_networks caused problems. YMMV.) > > We scan all outbound mail with the same SA cluster as our inbound scanning, > and I haven't seen misbehaviour I could blame on these settings since > sometime last summer (couple of corner-case oddities IIRC); before that it > would have been more than a year since I dug into them in detail and added > the msa_networks entries along with the upgrade to SA 3.2 (IIRC).
Kris, thanks for the good summary. Some new information. In this 2008 thread: http://old.nabble.com/ALL_TRUSTED-and-DOS_OE_TO_MX-td15659736.html ... Daryl says: "So if (and I'll admit I don't think this occurred to me before) you're running SA on outgoing mail on your MSA right after you receive it (it's not relayed to an intermediate machine) SA can't detect the MSA and the whole msa_networks thing doesn't work." That is exactly our setup - our outbound servers are accepting mail from customers and handing them off to the world, not going through any other servers. Could this be the issue? Also, I think that an example snippet of.cf illustrating and briefly explaining each of the three _networks options might be in order, and might make the reading, re-reading, and re-reading of the docs a little less painful. Writing one will also demonstrate that I've correctly grokked what's been going on here. :-) I'll take a stab at one. Royce
