<?xml version="1.0"?>
<CPDL> 
	<!-- Consent Policy Definition Language -->
	<!-- 
	
	Revision 20030903.1902 _M
	Added a number of <TEST> examples to IMPLEMENTATIONS including "combinatorial"
	test examples. One combinatorial test uses a logical combination of tests,
	another uses a weighting scheme.

	Revision 20030821.1500 _M
	Added IMPLEMENTATIONS element to create symmetry with the POLICIES element.
	and to resolve scope issues when multiple SYSTEMS might be represented within
	a single XML-CPDL, such as one from a database dump etc. There are a number
	of other changes that will ripple from this, and some changes that are pending
	based on feeback in the ASRG forum.. This is a preliminary update only... the
	next update will leave the example in a more consistent state.

	Revision 20030819.0146 _M
	Added concept of Groups as a structure for defining shareable elements.
	Added concept of Imports - the companion to Groups.
	Added the concept of Systems to identify entities for sharing policies.
	
	Revision 20030815.1553 _M
	Created boiler plate and initial site index.
	
	-->
	
    <SYSTEMS this="Local">
	
	    <!--
		The SYSTEMS section defines an implementation specific collection of
		entities (nodes, systems, etc...) that can participate in sharing policy
		elements. The general concept is that these "SYSTEMS" are connected to
		eachother in some way supported by the implementation and that through
		these connections the SYSTEMS can share elements of policies based on
		the sharing rules defined within the local policy for each SYSTEM.
		
		It is presumed that each SYSTEM contains one CPD (Consent Policy Definition).
		The CPD for each SYSTEM defines the sharing rules and the elements through
		the use of GROUPS.
		
		The first level of security is at the SYSTEM level. The only SYSTEMS that
		can "peer" with this SYSTEM are those that are defined in the local CPD. Any
		other attempt to connect (by any means supported in the implementation) would
		be rejected.
		
		This is also a good place to create general rules for the sharing policy.
		In general, security policies will be specified from the perspective of the
		local CPD.
		
		Securities established at this level can be overridden at a more specific
		level.
		-->
		
		<SYSTEM id="Local" locaion="localhost">
		
		    <!-- This System -->
	    
		</SYSTEM>
			
		<SYSTEM id="Upstream1" location="mymta.exampleisp.com">
		
		    <!-- 
			Upstream providers may offer added services based on the policies
			of their customers. For example, policies that refuse connections from
			abuseive networks might be aggregated and implemented in routing
			protocols to minimize traffic.
			
			A more ordinary example might be an upstream provider that offers store
			and forward SMTP services.
			-->

			<ALLOW-EXPORT />
			
			<!--
			For later work, the ALLOW-EXPORT element will probably not be empty.
			Rather it will contain elements that perform translations, establish
			security protocols such as passwords & encryption and so-forth. Some of
			this will be implementation specific and some will not.
			-->
		
		</SYSTEM>
			
		<SYSTEM id="Client1" location="client1.exampleclient.com">
		
			<!--
			Downstream clients may wish to export their policies upstream to
			optimize the performance of their systems. This is the other side
			of the concept described in the Upstream1 example.
			
			Although this is shown as an example using external systems, in a
			large scale email system the Upstream and Downstream SYSTEMS might
			simply be groups of servers - thereby allowing the internal aggregation
			of policies and by extension the optimization of email processing
			resources based on those aggregated policies.
			-->
			
			<ALLOW-IMPORT />
		
		</SYSTEM>
		
		<SYSTEM id="User1234" location="localhost/user1234@example.com">

		    <!--
			This is a representation of a single user, presumably hosted on this
			local hardware. The user has a CPD associated with them. In this case lets
			presume that this policy drives the SMTP service and the CPD of the user
			drives the local delivery agent. In this case the Local system may import
			policies from the individual users and implement those policies that
			are appropriate.
			-->
			
			<ALLOW-IMPORT>
			
			    <!--
				Just like the ALLOW-EXPORT element, the ALLOW-IMPORT element will describe
				the rules by which CPD elements can be imported into this policy, the security
				components that might be used, and so forth.
				
				When policy aggregation mechanisms are offered by an implementation then this
				section would be an appropriate place for defining aggregation parameters. For
				example a particular SYSTEM's ALLOW-IMPORT element might define a weight for
				all, or some subset of GROUPS that might be imported. Presumably there would
				be a counterpart GROUP import element that establishes a threshold such that
				if the number of systems exporting a particular policy exceeds this threshold
				then the policy would be adopted by this policy. This is only one possible
				policy aggregation mechanism.
				-->
			
			</ALLOW-IMPORT>
			
			<ALLOW-EXPORT>
			    <EXPORT id="UserActions" />
				
				<!--
				This is an example of how an export might be defined for a set of actions. It
				is important to note that GROUP, IMPORT, and EXPORT elements can be used to
				share any kinds of elements allowed by an implementation. This can be useful
				in a sysetm that provides services for user-specific actions. In this case,
				consider the scenario that many actions might be available to the systems admin
				such as BreakConnection, or SilentDelete, and so forth. It would be inappropriate
				for an end user to have access to these actions when defining their CPD. The
				solution in this case is to export a specific subset of actions that the user
				may apply in their policies.
				
				NOTE: As a general rule, if an EXPORT element is defined in an ALLOW-EXPORT then
				anything not specifically EXPORTED is witheld. This may end up being implementation
				specific, and possibly even switchable.
				-->
				
			</ALLOW-EXPORT>
		
		</SYSTEM>
	
		<SYSTEM id="User5678" location="localhost/user5678@example.com">
		  <ALLOW-IMPORT weight="1.00" no-conflicts="true" aggregation="UserRules" />
		  
		  <!--
		  In the above ALLOW-IMPORT the user's rules are given a weight of 1.00, presumably
		  an even share with all of the other policies that might be aggregated. The inputs
		  of those policies are weighed against an aggregation group called UserRules.
		  
		  The no-conflicts="true" attribute establishes that policies that conflict with
		  any explicit policies within this CPD will not be eligable for import.
		  
		  Later in this example we show the UserRules aggregation being imported against a
		  threshold. The indications in this example are that the threshold defines the
		  percentage of weighted users who have an identical policy. If the threshold is
		  reached then the aggregated policy element is adopted through the IMPORT tag.
		  
		  Note, this places those IMPORTED policies into the GROUP where the IMPORT tag resides,
		  if any. This means that aggregated policies can also be exported to other policies or
		  reused in this policy.
		  -->
		  
		</SYSTEM>

	</SYSTEMS>

	<IMPLEMENTATIONS>
	
		<!--
		The IMPLEMENTATIONS section defines the scope of TESTS and ACTIONS.
		The local system is assumed by default as it is within POLICIES.
		If a single XML-CPD document were representing a number of SYSTEMS then
		each IMPLEMENTATIONS section would require a system="<name>". We may
		consider enclosing IMPLEMENTATIONS and POLICIES within an appropriate
		SYSTEM tag to provide scope resolution without the need for an explicit
		"system" attribute... the concern right now is that this might cause
		some confusion with the current SYSTEM element useage that will force a
		number of additional changes. All of these changes are likely to be
		wrapped up in a later update to improve the symmetry of the XML-CPDL
		spec and to more closely comply with RFC3060.
		-->
	
		<TESTS>
		
			<!--
			The TESTS section defines local implementations for the tests that
			are available in a given environment. This is where the local system
			software interfaces with the policy to define the characteristics of
			a given message.
			-->
			
			<TEST id="Unknown_Sender" type="SCRIPT" method="CheckKnownSenders();" />
			
			<!-- 
			The above is a dummy example of how a given software might implement a test
			by defining a scripting language and a library of functions. Further
			examples will be created showing other possibilities as they are suggested.
			-->
			
			<!-- An example of a test that might simply be provided by the implementation -->
			<TEST id="NOLEGITCONTENT" type="INTERNAL" />
			
			<!--
			The NOLEGITCONTENT test is based on an example from Declude (www.declude.com). It's
			actually more of an anti-test. The test result is true if there is no obviously
			legitimate content in the message. It is intended for use in a weighting system such
			that if the test proves to be true nothing is done but if it is false then a value is
			subtracted from	the total weight. Essentially, if legitimate content is discovered in
			the message then it's "spamminess" is reduced. This example is in here to show how an
			INTERNAL test might be implemented and also to help with the combinatorial weighted test
			example below.
			
			ANOTHER IMPORTANT POINT about INTERNAL tests. It _may_ be preferable for systems
			implementing the XML-CPDL to implement all of the "well known" tests as INTERNAL so that
			there is no ambiguity about the performance or meaning of the test. This example is
			shown with no additional attributes in much the same way a "well known" test might be
			implemented, since additional attributes might suggest some variability about the test.
			
			Though it is not a requirement that INTERNAL tests be implemented without additional
			attributes, it might be preferable for "well known" tests to be implemented with the
			type INTERNAL and without any additional attributes to prevent any ambiguity.
			-->
			
			<!-- An example of an external test that produces a numerical weight result -->
			<TEST id="SPAMMANAGER" type="NUMERICAL-WEIGHT" method="/bin/spammanger.exe $message" />
			
			<!--
			The SPAMMANAGER test represents how an external progragram might be called with
			the expectation of a numerical result code indicating the weight or "Spamminess"
			of the test. The actual usage would be highly implementation specific - so for
			this example let's assume that the software expects a result code from 0-100 that
			represents a % probability that the message is spam. That being the case, let's also
			assume that this test evaluates numerically to the same value. We will use this test
			below with the weigted combinatorial test.
			-->

			<!-- Here we convert a numerical weight to a fraction representing a probability -->
			<TEST id="SPAMGR-PERCENT" type="FORMULA" input="SPAMMANAGER" method="(input/100)" />

			<!-- An example of an external test that produces a numerical symbol result -->
			<TEST id="SNIFFER" type="NUMERICAL-SYMBOL" method="/bin/messagesniffer.exe $message" />
			
			<!--
			The SNIFFER test represents how an external program might be called with the expectation
			of a numerical result code indicating a symbol. For example, Message Sniffer produces
			a different numerical result depending upon the group of heuristics that matches the
			message passed to it. In general, a zero result is considered to be "clean" while a
			non-zero result is considered to be some kind of spam. Note that this kind of test might
			also represent a virus scanner where a specific result code indicates the presence of
			a kind of virus etc. We will use this example below in our combinatorial examples.
			
			A test like this might be evaluated as a simple BOOLEAN result (the default evaluation
			for TEST elements) or it might be expanded by other tests (see below) to represent each
			of it's different result possibilities.
			-->
			
			<!-- When symbols are produced we may want to break them out into BOOLEAN tests -->
			<!-- The following test is true if the SNIFFER test value is 63 -->
			<TEST id="SNFGENERIC" type="EQUALITY" input="SNIFFER" test="63" />
			<TEST id="SNFEXPERIMENTAL" type="EQUALITY" input="SNIFFER" test="62" />
			<TEST id="SNFOBFUSCATION" type="EQUALITY" input="SNIFFER" test="61" />
			<TEST id="SNFGRAYHOSTING" type="EQUALITY" input="SNIFFER" test="60" />
			<TEST id="SNFGAMBLING" type="EQUALITY" input="SNIFFER" test="59" />
			<TEST id="SNFDEBT" type="EQUALITY" input="SNIFFER" test="58" />
			<TEST id="SNFGETRICH" type="EQUALITY" input="SNIFFER" test="57" />
			<TEST id="SNFINK" type="EQUALITY" input="SNIFFER" test="56" />
			<TEST id="SNFMALWARE" type="EQUALITY" input="SNIFFER" test="55" />
			<TEST id="SNFADULT" type="EQUALITY" input="SNIFFER" test="54" />
			<TEST id="SNFSCAM" type="EQUALITY" input="SNIFFER" test="53" />
			<TEST id="SNFDRUGS" type="EQUALITY" input="SNIFFER" test="52" />
			<TEST id="SNFSPAMWARE" type="EQUALITY" input="SNIFFER" test="51" />
			<TEST id="SNFMEDIATHEFT" type="EQUALITY" input="SNIFFER" test="50" />
			<TEST id="SNFANTIVIRUS" type="EQUALITY" input="SNIFFER" test="49" />
			<TEST id="SNFINSURANCE" type="EQUALITY" input="SNIFFER" test="48" />
			<TEST id="SNFTRAVEL" type="EQUALITY" input="SNIFFER" test="47" />
			<TEST id="SNFCLEAN" type="EQUALITY" input="SNIFFER" test="0" />
			
			<!-- ip4 DNS based RBL type tests might be implemented this way -->
			
			<TEST id="DSBL" type="IP4DNSBL" service="list.dsbl.org" result="*" />
			<TEST id="MONKEYFORMMAIL" type="IP4DNSBL" service="formmail.relays.monkeys.com" result="*" />
			<TEST id="MONKEYPROXIES" type="IP4DNSBL" service="proxies.relays.monkeys.com" result="*" />
			<TEST id="NJABL" type="IP4DNSBL" service="dnsbl.njabl.org" result="127.0.0.2" />
			<TEST id="VOX" type="IP4DNSBL" service="vox.schpider.com" result="127.0.0.2" />
			<TEST id="BLITZEDALL" type="IP4DNSBL" service="opm.blitzed.org" result="*" />
			<TEST id="EASYNET-DNSBL" type="IP4DNSBL" service="blackholes.easynet.nl" result="127.0.0.2" />
			<TEST id="EASYNET-PROXIES" type="IP4DNSBL" service="proxies.blackholes.easynet.nl" result="*" />
			<TEST id="IPWHOIS" type="IP4DNSBL" service="ipwhois.rfc-ignorant.org" result="127.0.0.6" />
			<TEST id="SORBS-HTTP" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.2" />
			<TEST id="SORBS-SOCKS" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.3" />
			<TEST id="SORBS-MISC" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.4" />
			<TEST id="SORBS-SMTP" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.5" />
			<TEST id="SORBS-SPAM" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.6" />
			<TEST id="SORBS-WEB" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.7" />
			<TEST id="SORBS-BLOCK" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.8" />
			<TEST id="SORBS-ZOMBIE" type="IP4DNSBL" service="dnsbl.sorbs.net" result="127.0.0.9" />
			<TEST id="SPAMBAG" type="IP4DNSBL" service="blacklist.spambag.org" result="127.0.0.2" />
			<TEST id="UCEB" type="IP4DNSBL" service="blackholes.uceb.org" result="*" />
			<TEST id="ORDB" type="IP4DNSBL" service="relays.ordb.org" result="*" />
			<TEST id="SPAMCOP" type="IP4DNSBL" service="bl.spamcop.net" result="127.0.0.2" />
			<TEST id="FABELSOURCES" type="IP4DNSBL" service="spamsources.fabel.dk" result="127.0.0.2" />
			<TEST id="FIVETEN-SPAM" type="IP4DNSBL" service="blackholes.five-ten-sg.com" result="127.0.0.2" />
			<TEST id="FIVETEN-BULK" type="IP4DNSBL" service="blackholes.five-ten-sg.com" result="127.0.0.4" />
			<TEST id="FIVETEN-MULTISTAGE" type="IP4DNSBL" service="blackholes.five-ten-sg.com" result="127.0.0.5" />
			<TEST id="FIVETEN-SPAMSUPPORT" type="IP4DNSBL" service="blackholes.five-ten-sg.com" result="127.0.0.7" />
			<TEST id="FIVETEN-MISC" type="IP4DNSBL" service="blackholes.five-ten-sg.com" result="127.0.0.9" />
			<TEST id="FIVETEN-SINGLESTAGE" type="IP4DNSBL" service="blackholes.five-ten-sg.com" result="127.0.0.6" />
			<TEST id="FIVETEN-FREE" type="IP4DNSBL" service="blackholes.five-ten-sg.com" result="127.0.0.12" />
			<TEST id="INTERSIL" type="IP4DNSBL" service="blackholes.intersil.net" result="127.0.0.2" />
			<TEST id="SPAMHAUS" type="IP4DNSBL" service="sbl.spamhaus.org" result="127.0.0.2" />
			<TEST id="CBL" type="IP4DNSBL" service="cbl.abuseat.org" result="127.0.0.2" />
			
			<!-- Envelope sender RHSBL tests might be implemented this way -->
			
			<TEST id="DSN" type="IP4RHSBL" service="dsn.rfc-ignorant.org" result="127.0.0.2" />
			<TEST id="NOABUSE" type="IP4RHSBL" service="abuse.rfc-ignorant.org" result="127.0.0.4" />
			<TEST id="NOPOSTMASTER" type="IP4RHSBL" service="postmaster.rfc-ignorant.org" result="127.0.0.3" />
			<TEST id="SECURITYSAGE" type="IP4RHSBL" service="blackhole.securitysage.com" result="*" />
			<TEST id="SORBS-BADCONF" type="IP4RHSBL" service="dnsbl.sorbs.net" result="127.0.0.11" />
			<TEST id="SORBS-NOMAIL" type="IP4RHSBL" service="dnsbl.sorbs.net" result="127.0.0.12" />
			<TEST id="MAILPOLICE-BULK" type="IP4RHSBL" service="bulk.rhs.mailpolice.com" result="127.0.0.2" />
			<TEST id="MAILPOLICE-PORN" type="IP4RHSBL" service="porn.rhs.mailpolice.com" result="127.0.0.2" />
			
			<!--
			Combining tests to produce more complex models.
			Most of the best antispam software out there currently evaluates a number of test and
			then combines them to produce a useful result. It has been shown that combining a number
			of tests is more accurate than using any single test in general. In a CDL, this concept
			is represented by creating a new "TEST" that represents the combined value of the other
			tests.
			
			For the purposes of expressing this idea, let's assume that "naked" tests default to
			producing a true or false value. Let's also assume that in numerical terms the result of
			a test is true if it is not zero. Using this basic concept will allow us to unify all tests
			for use in combinatorial scenarios by expressing and interpreting a "value" attribute. When
			a test is evaluated in a BOOLEAN context, a nonzero value is seen as true, while a zero
			value is seen as false. Let us also define that the default value for "true" is 1.
			
			What follows are some examples of combinatorial tests that might be developed using
			these rules.
			-->
			
			<!-- Developing a weighted test scheme might work like this... -->
			
			<TEST id="SPAMWEIGHT" type="WEIGHTEDSUM">
				<WEIGHT test="DNSBL" iftrue="30" iffalse="0" />
			 	<WEIGHT test="MONKEYFORMMAIL" iftrue="30" iffalse="0" />
			 	<WEIGHT test="NOLEGITCONTENT" iftrue="0" iffalse="-10" />
				<WEIGHT test="SPAMMANAGER" /> <!-- no iftrue/iffalse = no translation -->
			</TEST>
			
			<!-- All tests must ultimately become BOOLEAN for use in policies -->
			<!-- Here is an example of how to establish a BOOLEAN tests from a WEIGHTED test -->
			
			<TEST id="WEIGHT50" type="THRESHOLD" input="SPAMWEIGHT" threshold="50" />
			<TEST id="WEIGHT100" type="THRESHOLD" input="SPAMWEIGHT" threshold="100" />
			<TEST id="WEIGHT250" type="THRESHOLD" input="SPAMWEIGHT" threshold="250" />
			
			<!-- Of course we might need to combine serveral tests and select by priority -->
			<!-- Here the test with the highest priority determines the value of this test -->
			<!-- In this case a lower priority number indicates a higher priority -->
			
			<TEST id="HIGHESTWEIGHT" type="PRIORITY">
				<PRIORITY test="WHITELISTED" priority="0" />
				<!-- Below is an example of overwriting a value if the item is selected -->
				<PRIORITY test="WEIGHT250" priority="1" value="500" />
				<PRIORITY test="WEIGHT100" priority="2" />
				<PRIORITY test="WEIGHT50" priority="3" />
			</TEST>
			
			<!-- Another way of combining weighted tests is by creating a probability number -->
			<!-- This example sums the weights and develops a number between 0 and 1 -->
			<!-- 0 represents no tests true while 1 represents all tests true. -->
			<!-- Each test is weighted as in the SPAMWEIGHT test above -->
			
			<TEST id="WEIGHTEDFRACTION" type="WEIGTEDFRACTION" >
				<WEIGHT test="SNFGRAY" iftrue="5" iffalse="0" />
				<WEIGHT test="SNFCLEAN" iftrue="-5" iffalse="50" />
				<WEIGHT test="DNSBL" iftrue="30" iffalse="0" />
			 	<WEIGHT test="MONKEYFORMMAIL" iftrue="30" iffalse="0" />
			 	<WEIGHT test="NOLEGITCONTENT" iftrue="0" iffalse="-10" />
			</TEST>
			
			<!--
			The results of the WEIGHTEDFRACTION type test are calculated as follows.
			The highest possible total weight is determined. In this case 5+50+30+30=115.
			The lowest possible total weight is determined. In this case 0-5+0+0-10=-15.
			The difference between the highest and lowest values (the "range" is 130 (max-min).
			The total weight is calculated and the minimum is subtracted to bias the result,
			thus ensuring that the end result will always be a positive number starting at 0.
			The result of this equation (the corrected number) in this case is always between
			0 and 130. We take the corrected number and divide it by the "range" to get a
			fraction between 0.0 and 1.0.
			
			So, if the SNFCLEAN, DNSBL, and MONKEYFORMMAIL tests were true the end result
			would be... 30+30-5 = 55. 55 - (-15) = 70. 70/130 = 0.53846...
			-->
			
			<!--
			There are a wide range of methods for numerically combining test results. It's 
			probably not a good idea to try and show them all but more examples will be added
			if suggested. The important point is to show that it can be done and to point to
			examples of how that might work.
			-->
			
			<!-- Another way of combining tests is with a boolean tree. -->
			<!-- The following example shows how to combine tests using boolean logic. -->
			
			<TEST id="ISSPAM" type="BOOLEAN">
				<AND>
					<NOT><BOOLEAN test="WHITELISTED" /></NOT>
					<OR>
						<BOOLEAN test="WEIGHT250" />
						<BOOLEAN test="WEIGHT100" />
						<BOOLEAN test="MAILPOLICE-PORN" />
					</OR>
				</AND>
			</TEST>
			
		</TESTS>
		
		<ACTIONS>
			
			<!-- 
			The ACTIONS section defines the local implementations for actions that
			are available in a given environment. This is where the local system
			software interfaces with the policy to provide the response mechanisms
			that are called for in the policy.
			-->
			
			<ACTION id="Reject" method="Reject();" />
			
			<!-- 
			The above is a dummy example of how a given software might implement an
			action by defining a scripting language and a library of functions. Further
			examples will be created showing other possibilities as they are suggested.
			-->
			
			<GROUP id="UserActions">
	
			<!-- These actions exportable to user policies... see other notes! -->
			
				<ACTION id="Quarantine" method="Quaratine();" />
				<ACTION id="Spambox">
					<METHOD>
				       Redirect("$user/Spambox");
					</METHOD>
				</ACTION>
			
			</GROUP>
	
		<!-- 
			Below we import the "Standard" implementation elements for this CPD. It has
			been pointed out that a CPDL should allow the implementation specific parts
			to be separated from the "standard" parts. One way this can be done is by
			providing an "include" type functionality... here we do this by overloading
			the IMPORT element... seems natural enough.
			
			Another way of handling the separation would be that a software that implements
			this CPDL would naturally get it's implementation specific components from a
			separate file. I belive that the specification for the CPDL should support both
			options.
			-->
	
			<IMPORT file="/etc/CPDL/standards.xml" />
			
		</ACTIONS>

	</IMPLEMENTATIONS>
	
	<POLICIES>
	
		<!-- 
		The POLICIES section defines a collection policies and will probably also
		define the rules for inheriting or share these policies by grouping the
		policies into collections with a specific security profile. A lot of work
		must be done before we will know what those security profiles will look like
		so none are represented here yet.
		-->

        	<GROUP id="Imports" name="Imported Policies" active="false">
		
			<!--
			Here is an inactive group of policies. This means that the group is not
			directly part of the active policy, but may be re-used elsewhere.
			
			The use of an active flag may not survivie the evolution of this language
			but it is one way to allow for groups that are only defined for their
			"workspace" value.
			
			Another method would be to place "workspace" groups in the root or in
			some subgroups defined in the CPD. This too must evolve.
			
			At any rate, this group contains all of the policy elements that have been
			imported fromother systems. These imported policies will be re-used in the
			"Local" group (and made active as a result) to show how groups can be
			IMPORTED locally to provide another kind of structure.
			-->

        		<IMPORT system="Client1" id="MustWhiteRules" />
		
			<IMPORT aggregation="UserRules" threshold="0.60" />
		
		</GROUP>
		
        	<GROUP system="Local" id="CorePolicy" name="Core Policy" active="true">

			<!--
			Below we import a locally defined group.
			Note that the system attribute is absent indicating that the default
			local system is implied.
			
			The policies that are defined in the Imports group were inactive. Now that
			they are IMPORTed here they will become active because they are in the
			context of an active group.
			-->

			<IMPORT id="Imports" />
			
			<POLICY name="Reject Unkown Senders"> 
			
				<!-- 
				Example Policy Template 
				A policy describes what to do with the messages that are received. This is
				done by establishing CONDITIONS based on collections of TESTS and then
				defining RESPONSES based on collections of ACTIONS. In general, therfore,
				a POLICY says "if the conditions are thus then take the following action(s)".
				-->
				
				<CONDITIONS>
				
					<!-- 
					A CONDITIONS block in a policy definition combines a set of tests that
					describe the desired conditions surrounding a given message. In general
					the individual TEST elements are combined with a logical AND unless otherwise
					defined. As a result, ALL of the tests must be true for the conditions to
					be true (by default). Examples of more complex logic will come later.
					-->
				
					<TEST id="Unknown_Sender" />
					
					<!-- The Unknown_Sender test must be defined in the TESTS section -->
				
				</CONDITIONS>
				
				<RESPONSES>
				
					<!-- 
					A RESPONSES block in a policy definition combines a set of actions that
					should be taken if the conditions are met. This area _MAY_ warrent some
					mechanism for scripting, however the preferred method for handling a
					complex response would be to fully describe that response in the ACTIONS
					section so that it could be used simply in a RESPONSES block. In this way
					an implementation that wishes to offer scripting as part of it's RESPONSE
					mechanism can keep that scripting mecahnism clearly in an implementation-
					specific section of the document. This makes it possible to share policies
					between different systems as long as the different systems can agree upon
					the names for the ACTIONS and/or TESTS that are defined. This will be
					particularly important where "well known" TESTS and ACTIONS are implemented
					since the IDs for the "well known" TESTS and ACTIONS would be part of a
					standards document.
					-->
					
					<ACTION id="Reject" />
					
					<!-- The Reject action must be defined in the TESTS section -->
				
				</RESPONSES>
			</POLICY>  
        	</GROUP>
	</POLICIES>
</CPDL>
