The following is a complex inheritance structure to express how inheritance works in CanIt:
base:default | +--------------------------------+--------------------------------+ | | serviceprovider-com:default widgets-co-uk:default | | +---------------------------------------------+ widgets-co-uk:bob | | examplecorp-com:default othercorp-com:default | | +--------------------------+ companyname:default | | | example-org:default example-com:default companyname:bob | | +----------------+ example-com:bob | | example-org:bob example-org:sue
Let's pretend that your name is Bob. We also are going to pretend that you work for the non-profit arm of Examplecorp and your email address is firstname.lastname@example.org.
Examplecorp also has a commercial branch with the domain example.com and by chance they also employ another person named Bob. When you and the other Bob access your CanIt streams, you both go to a stream simply called 'bob'. But it is not the same stream. You and the other Bob are able to work independently; collect different mail, create different rules and have different preferences, all because you are in different realms.
Realms are used in order to differentiate domains or groups of domains in the CanIt system. It is possible that multiple domains could share the same realm in order to share all of the same rules, but then you and Bob could not co-exist given this streaming method since both of you would be trying to use the same stream. If email@example.com also belonged to you, this would be ideal, but since it is a different person in our example, we would have to change the mapping so that your stream name was something unique (typically your full email address).
The most important rules that CanIt cares about are the ones that you or your administrator apply directly to your realm. If you create a rule here that is directly opposed to other rules further up the ladder, your rule wins every time. But these rules are limited in scope to only the people within your stream. Usually this is only you, unless this is a distribution group. This means that any rules you create will not affect your coworker Sue, nor will they affect any of the other Bob's in the diagram. The best way to look at the diagram is to realize that rules can only travel down, but that rules created further down the diagram trump those created above.
Default in Your Realm
There is never going to be a case where you specify all of the rules in your own stream; in fact, you may not have specified any. So where does CanIt look next? The answer is that it will look to the default rules for your domain. These are rules that your administrator or an administrator higher up the ladder have set up to apply to everyone with an example.org account. These rule apply to you as well as Sue, but not anyone from example.com of further up.
The lingo starts to break down a little when there are this many levels, but the important thing to note here is that example-org and example-com are referred to as subrealms within the examplecorp-com realm. examplecorp-com and othercorp-com are then both subrealms of the serviceprovider-com realm. Finally serviceprovider-com and widgets-co-uk are subrealms of the base realm.
After checking all of the rules in your realms default stream CanIt will continue to check the default streams in each successive parent realms default stream until it eventually finds a rule. If it finds a rule when it gets to examplecorp-com which it did not find in example-org, for example, it will record the rule and not bother looking any higher, since this rule is more important than any applied in the parent realms.
At the very top is is the base realm. This houses a generic set of rules to be applied to every user within the entire CanIt cluster. For our Hosted CanIt solution applies to all of the thousands of domains that we host. The same will be true on a smaller scale if you are served by a re-seller who hosts their own instance of our CanIt-Domain-Pro product. While this may make the base realm seem like it is very important, it is important to remember that only rules that have yet to be defined at any other stage will be pulled from here. Having this breadth of control does give us the ability to react to new spamming phenomena quickly and apply rules to all customers immediately.
How to See Your Inheritance
The diagram is as complex as it is to show that levels of complexity that you might see in a CanIt set-up. The Bob that you have been impersonating in on the highest end of complexity where he works for a division of a larger company who is managed by a service provider, all of which is hosted by Roaring Penguin. On the opposite end there is widgets-co-uk which is a single domain hosted directly by Roaring Penguin without anything else in between.
In the WebUI there is a handy tool in the User/Stream area in the top-right corner that allows you to see where your rules are inherited from. You can access this simply by clicking the Details link beside the stream you are currently viewing. This is what we would see for example-org:bob:
example-org:bob <-- example-org:default <-- examplecorp-com:default <-- serviceprovider-com:default <-- base:default