On Tue, Apr 6, 2010 at 1:01 PM, Royce Williams <royce.willi...@gmail.com> wrote: > 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.
OK, here is my first pass at a *_networks example. Feedback welcome. I've included comments and whitespace, to make it easy to digest for others trying to wrap their head around this in the future. If you have a minor correction, please send it to me off-list and I will compile. If you spot a fundamental issue, please point it out on-list (to quickly get consensus). I'm specifically interested in getting other server type examples so that lots of bases are covered for educational purposes. I also need some help understanding these two adjacent paragraphs of the msa_networks explanation so that I can fold them in: "All relays found in the message headers after the MSA relay will take on the same trusted and internal classifcations as the MSA relay itself, as defined by your trusted_networks and internal_networks configuration." "For example, if the MSA relay is trusted and internal so will all of the relays that precede it." The use of the word "after" in the first paragraph and "precede" in the second paragraph confuse me. "after" appears to be meant in the chronological sense, and "precede" appears to be the order as presented when viewing the headers -- is this correct? Logically, this would make more sense than the reverse. OK, here's my draft example. #----------------------------------------------------------------------- # This example illustrates the interaction between network # configuration parameters (*_networks) in SpamAssassin's .cf files. # # Most SA setups will not include all of these types of servers, but # they are all included for demonstration purposes. # # Given the following networks and systems: # # 10.0.0.0/24 - Dedicated MTA/MXes, handling inbound mail. # 10.1.1.0/24 - Dedicated MSAs at the border, handling outbound mail. # 10.2.0.0/16 - Customer dynamic/dialup/statics allowed to send mail. # 10.3.3.0/24 - A trusted third-party relay (like Postini). # 10.4.4.0/24 - A set of hybrid MX/MSA systems. # 10.5.5.5 - A legacy inbound mail server used for ETRN. # 10.6.6.6 - intermediate outbound server for internal workstations. # # ... then the local.cf could contain: #---------------------------- # trusted_networks #---------------------------- # # Contains: Relays that may relay spam, but will never originate it, # and will never forge headers. This must also contain *all* # members of internal_networks. # # Should not contain: Any system that could originate spam # or forge headers. # # Effects: DNSBL checks will never query for hosts on these networks. # # Dedicated MXes. trusted_networks 10.0.0.0/24 # Dedicated MSAs. trusted_networks 10.1.1.0/24 # Postini. trusted_networks 10.3.3.0/24 # Hybrid MX/MSA systems. trusted_networks 10.4.4.0/24 # ETRN server (baton). trusted_networks 10.5.5.5 # handoff.example.net - our internal intermediate relay. trusted_networks 10.6.6.6 #---------------------------- # msa_networks #---------------------------- # # Contains: Your relay that accept mail from your authenticated users, # by IP list, SMTP AUTH, POP-before-SMTP, etc. # # Should not contain: Multipurpose MSA/MX systems or any other # systems that accept non-authenticated/verified submission. # # Effects: Headers added by subsequent relays inherit the "trust" # and "internal" status of the MSA. Also, messages submitted by # authenticated/verified users to these systems will not be # subject to tests designed to detect dynamic IP DNS names, direct # messages from clients to MXes, etc. [NEED MORE HERE] # # Dedicated MSAs. msa_networks 10.1.1.0/24 # Our internal intermediate relay (handoff.example.net) 10.5.5.5 #---------------------------- # internal_networks #---------------------------- # # Contains: MXes or internal relays. # # Should not contain: trusted hosts that are not MXes or internal # relays. For example, MSAs should not be included here. # # Effects: Used when checking dialup or dynamic IP address blocklists, # in order to detect direct-to-MX spamming. [NEED MORE HERE] # # Dedicated MXes. internal_networks 10.0.0.0/24 # ETRN server (baton). internal_networks 10.5.5.5 # # Note that none of these parameters contains the end-user network space # (10.2.0.0/16). # # (end of example) #-----------------------------------------------------------------------
