Whoops - forgot to reply-all; resending with minor modifications. On Sat, Apr 3, 2010 at 9:10 AM, RW <rwmailli...@googlemail.com> wrote: > On Sat, 3 Apr 2010 06:18:25 -0800 > Royce Williams <royce.willi...@gmail.com> wrote: > >> On Fri, Apr 2, 2010 at 11:20 PM, Henrik K <h...@hege.li> wrote: >> > On Fri, Apr 02, 2010 at 01:45:57PM -0800, 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. >> > >> > All dynamic rules look at external relays. So if you have SA on the >> > relay that accepts mail from dynamic space, you need to include all >> > that in internal_networks and disable ALL_TRUSTED since it would >> > always hit. >> >> Interesting. I do have SA on my MSAs. That might be the single knob >> that I am looking for. >> >> Some folks aren't big enough to have separated MTAs and MSAs; for >> their benefit, is there any other approach that would work? My >> imagined mua_networks would fit this bill, and it would allow the same >> SA configuration on both MTAs and MSAs, which would make my life as a >> sysadmin easier. > > Putting the address ranges into internal_networks is what you do if you > *don't* have separate MSAs and MX servers. Otherwise you you put the > MSAs into msa_networks and internal_networks. Anything that connects to > a server in msa_networks inherits the internal/trusted status of the > msa. > > Even if you don't or can't do any of the above, SA will pick-up and on > authentication recorded in the received header and for the most part do > the right thing, e.g. it won't run PBL/DUL lookups.
My understanding is that if my own dynamics inherit the MSA's internal/trusted status, then the headers added by those hosts are assumed to be genuine. That's a behavior I'm trying to avoid. Maybe I'm misunderstanding some rule fundamentals. Some rules are designed to detect MUAs, but don't appear to be affected by the contents of msa_networks. Examples are the Outlook-detecting rules like DOS_OE_TO_MX, some of the HELO-enforcement rules, and the letter-number-letter hostname rules. From my testing, even though all of my MSAs have msa_networks fully populated, these rules are applied to all clients using my MSAs. If I enumerate and disable all of the MUA-spanking rules, I get the whack-a-mole problem that I have today. If I upgrade SA or update to get new rulesets, new MUA spanking-rules may appear. I then have to track down new false positives from my customer base. It is difficult to test the rule changes in advance, because of the sheer number of MUA families and versions. I also considered John Hardin's idea about adding negative points, which would work, but is not precise enough for me. I want my infected customers to be spanked for spam as much as possible -- but not for being clients. Picking an arbitrary negative number will result in more customer spam getting out. In other words, I want to use SA to express that my dynamics: * are allowed to submit * should not be trusted to insert only good headers * should not be punished for being MUAs * should not be punished for being dynamic * should be subject to all other rules Is there a way to express this? Royce
